12017-07-05T00:01:22 *** PaulCapestany has quit IRC
22017-07-05T00:02:46 *** PaulCapestany has joined #bitcoin-core-dev
32017-07-05T00:04:59 *** btcdrak has joined #bitcoin-core-dev
42017-07-05T00:07:30 *** PaulCapestany has quit IRC
52017-07-05T00:09:33 *** PaulCapestany has joined #bitcoin-core-dev
62017-07-05T00:09:57 *** chjj has quit IRC
72017-07-05T00:14:28 *** PaulCapestany has quit IRC
82017-07-05T00:20:20 *** PaulCapestany has joined #bitcoin-core-dev
92017-07-05T00:24:04 *** PaulCapestany has quit IRC
102017-07-05T00:26:19 *** PaulCapestany has joined #bitcoin-core-dev
112017-07-05T00:33:27 *** chjj has joined #bitcoin-core-dev
122017-07-05T00:34:04 *** Cheeseo has quit IRC
132017-07-05T00:39:24 *** btcdrak has quit IRC
142017-07-05T00:40:23 *** btcdrak has joined #bitcoin-core-dev
152017-07-05T00:51:51 *** Aaronvan_ has joined #bitcoin-core-dev
162017-07-05T00:54:40 *** AaronvanW has quit IRC
172017-07-05T01:06:03 *** Aaronvan_ has quit IRC
182017-07-05T01:06:39 *** AaronvanW has joined #bitcoin-core-dev
192017-07-05T01:07:47 *** dabura667 has joined #bitcoin-core-dev
202017-07-05T01:10:09 *** unholymachine has joined #bitcoin-core-dev
212017-07-05T01:10:52 *** AaronvanW has quit IRC
222017-07-05T01:32:11 *** fengling_ is now known as fengling
232017-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
242017-07-05T02:45:19 *** ivan_ has joined #bitcoin-core-dev
252017-07-05T02:55:24 *** RubenSomsen has joined #bitcoin-core-dev
262017-07-05T02:56:49 *** RubenSomsen has quit IRC
272017-07-05T02:57:10 *** RubenSomsen has joined #bitcoin-core-dev
282017-07-05T03:06:05 *** ivan_ is now known as ivan
292017-07-05T03:10:17 *** echonaut has quit IRC
302017-07-05T03:10:30 *** echonaut has joined #bitcoin-core-dev
312017-07-05T03:23:44 *** Murch has joined #bitcoin-core-dev
322017-07-05T03:28:25 *** Murch has quit IRC
332017-07-05T04:03:04 *** justan0theruser has joined #bitcoin-core-dev
342017-07-05T04:06:08 *** justanotheruser has quit IRC
352017-07-05T04:08:20 *** AaronvanW has joined #bitcoin-core-dev
362017-07-05T04:11:47 *** atroxes has quit IRC
372017-07-05T04:12:25 *** draadpiraat[m] has quit IRC
382017-07-05T04:12:46 *** AaronvanW has quit IRC
392017-07-05T04:12:56 *** atroxes has joined #bitcoin-core-dev
402017-07-05T04:13:40 *** draadpiraat[m] has joined #bitcoin-core-dev
412017-07-05T04:14:48 *** coredump_ has joined #bitcoin-core-dev
422017-07-05T04:18:27 *** goofie has quit IRC
432017-07-05T04:20:22 *** cysm has quit IRC
442017-07-05T04:24:01 *** justan0theruser has quit IRC
452017-07-05T04:24:19 *** justanotheruser has joined #bitcoin-core-dev
462017-07-05T04:34:13 *** cysm has joined #bitcoin-core-dev
472017-07-05T06:09:57 *** AaronvanW has joined #bitcoin-core-dev
482017-07-05T06:14:05 *** AaronvanW has quit IRC
492017-07-05T06:25:11 *** afk11 has quit IRC
502017-07-05T06:25:56 *** afk11 has joined #bitcoin-core-dev
512017-07-05T06:34:43 *** Ylbam has joined #bitcoin-core-dev
522017-07-05T06:38:02 *** arowser has quit IRC
532017-07-05T06:44:09 *** arowser has joined #bitcoin-core-dev
542017-07-05T06:47:15 *** RubenSomsen has quit IRC
552017-07-05T07:02:26 *** goatpig has joined #bitcoin-core-dev
562017-07-05T07:37:23 *** coredump_ has quit IRC
572017-07-05T07:40:24 *** laurentmt has joined #bitcoin-core-dev
582017-07-05T07:46:04 *** laurentmt has quit IRC
592017-07-05T08:10:40 *** AaronvanW has joined #bitcoin-core-dev
602017-07-05T08:15:08 *** AaronvanW has quit IRC
612017-07-05T08:15:25 *** schnerchi has quit IRC
622017-07-05T08:21:39 *** timothy has joined #bitcoin-core-dev
632017-07-05T08:24:22 *** schnerchi has joined #bitcoin-core-dev
642017-07-05T08:25:16 *** Deadhand has quit IRC
652017-07-05T08:29:05 *** Deadhand has joined #bitcoin-core-dev
662017-07-05T08:54:56 *** riemann has joined #bitcoin-core-dev
672017-07-05T08:58:13 *** Ylbam has quit IRC
682017-07-05T09:11:59 *** AaronvanW has joined #bitcoin-core-dev
692017-07-05T09:23:25 *** Aaronvan_ has joined #bitcoin-core-dev
702017-07-05T09:26:23 *** AaronvanW has quit IRC
712017-07-05T09:30:54 *** Guyver2 has joined #bitcoin-core-dev
722017-07-05T10:00:44 *** SopaXorzTaker has joined #bitcoin-core-dev
732017-07-05T10:25:31 *** JackH has joined #bitcoin-core-dev
742017-07-05T10:26:53 *** Aaronvan_ has quit IRC
752017-07-05T10:28:05 *** AaronvanW has joined #bitcoin-core-dev
762017-07-05T10:35:44 *** vicenteH has joined #bitcoin-core-dev
772017-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
782017-07-05T12:03:36 *** dabura667 has quit IRC
792017-07-05T12:05:11 *** belcher_ has joined #bitcoin-core-dev
802017-07-05T12:39:07 *** AaronvanW_ has joined #bitcoin-core-dev
812017-07-05T12:45:59 *** talmai has joined #bitcoin-core-dev
822017-07-05T13:07:24 *** Guyver2_ has joined #bitcoin-core-dev
832017-07-05T13:09:48 *** Guyver2 has quit IRC
842017-07-05T13:09:57 *** Guyver2_ is now known as Guyver2
852017-07-05T13:16:40 *** Dyaheon has quit IRC
862017-07-05T13:17:58 *** Dyaheon has joined #bitcoin-core-dev
872017-07-05T13:24:10 *** Chris_Stewart_5 has joined #bitcoin-core-dev
882017-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
892017-07-05T13:34:43 *** Chris_Stewart_5 has quit IRC
902017-07-05T13:43:22 *** BartokIT has joined #bitcoin-core-dev
912017-07-05T13:47:22 *** Guyver2_ has joined #bitcoin-core-dev
922017-07-05T13:49:53 *** BartokIT has quit IRC
932017-07-05T13:50:38 *** Guyver2 has quit IRC
942017-07-05T13:50:45 *** Guyver2_ is now known as Guyver2
952017-07-05T14:07:37 *** Dejah has joined #bitcoin-core-dev
962017-07-05T14:11:57 *** Dejah has quit IRC
972017-07-05T14:15:56 *** talmai has quit IRC
982017-07-05T14:15:59 *** Margarita2 has joined #bitcoin-core-dev
992017-07-05T14:19:13 *** Aaronvan_ has joined #bitcoin-core-dev
1002017-07-05T14:20:14 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1012017-07-05T14:22:25 *** AaronvanW has quit IRC
1022017-07-05T14:23:20 *** echonaut has quit IRC
1032017-07-05T14:23:37 *** echonaut has joined #bitcoin-core-dev
1042017-07-05T14:26:13 *** Guyver2 has quit IRC
1052017-07-05T14:27:08 *** Guyver2 has joined #bitcoin-core-dev
1062017-07-05T14:30:35 *** JackH has quit IRC
1072017-07-05T14:34:02 *** musalbas has quit IRC
1082017-07-05T14:36:09 *** musalbas has joined #bitcoin-core-dev
1092017-07-05T14:40:48 *** Chris_Stewart_5 has quit IRC
1102017-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
1112017-07-05T14:56:59 *** riemann has quit IRC
1122017-07-05T15:17:04 *** Guest86952 has quit IRC
1132017-07-05T15:17:26 *** tripleslash has joined #bitcoin-core-dev
1142017-07-05T15:22:05 *** Dyaheon has quit IRC
1152017-07-05T15:22:41 *** Dyaheon has joined #bitcoin-core-dev
1162017-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
1172017-07-05T15:46:07 *** Yogaqueef has joined #bitcoin-core-dev
1182017-07-05T15:46:16 *** Yogaqueef has quit IRC
1192017-07-05T16:15:39 *** isis has left #bitcoin-core-dev
1202017-07-05T16:36:38 *** Ylbam has joined #bitcoin-core-dev
1212017-07-05T16:38:38 *** chjj has quit IRC
1222017-07-05T16:46:23 *** tiagotrs has joined #bitcoin-core-dev
1232017-07-05T16:51:34 *** RoyceX has quit IRC
1242017-07-05T16:51:36 *** Cheeseo has joined #bitcoin-core-dev
1252017-07-05T16:54:15 *** Aaronvan_ has quit IRC
1262017-07-05T17:12:59 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1272017-07-05T17:26:28 *** Dyaheon has quit IRC
1282017-07-05T17:28:16 *** Dyaheon has joined #bitcoin-core-dev
1292017-07-05T17:31:04 *** ovovo has joined #bitcoin-core-dev
1302017-07-05T17:33:45 *** vicenteH has quit IRC
1312017-07-05T17:34:27 *** owowo has quit IRC
1322017-07-05T17:34:55 *** timothy has quit IRC
1332017-07-05T17:38:09 <earlz> Is there a know minimum gcc version for compiling Bitcoin Core?
1342017-07-05T17:42:59 *** Murch has joined #bitcoin-core-dev
1352017-07-05T17:43:11 *** chjj has joined #bitcoin-core-dev
1362017-07-05T17:46:21 *** Giszmo has quit IRC
1372017-07-05T17:51:21 <sipa> 4.8
1382017-07-05T17:55:57 *** RubenSomsen has joined #bitcoin-core-dev
1392017-07-05T18:04:51 *** talmai has joined #bitcoin-core-dev
1402017-07-05T18:11:51 *** Margarita2 has quit IRC
1412017-07-05T18:14:34 *** Lilly2 has joined #bitcoin-core-dev
1422017-07-05T18:27:50 *** Guyver2_ has joined #bitcoin-core-dev
1432017-07-05T18:29:52 *** riemann has joined #bitcoin-core-dev
1442017-07-05T18:31:13 *** Guyver2 has quit IRC
1452017-07-05T18:31:13 *** Guyver2_ is now known as Guyver2
1462017-07-05T18:38:08 *** SopaXorzTaker has quit IRC
1472017-07-05T18:39:23 *** Murch has quit IRC
1482017-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
1492017-07-05T18:43:13 *** Chris_Stewart_5 has quit IRC
1502017-07-05T18:54:00 *** tmddzk has joined #bitcoin-core-dev
1512017-07-05T18:55:23 *** ovovo is now known as owowo
1522017-07-05T18:57:50 *** ajd__ has quit IRC
1532017-07-05T19:02:59 *** Yogaqueef has joined #bitcoin-core-dev
1542017-07-05T19:08:43 *** schmidty has joined #bitcoin-core-dev
1552017-07-05T19:11:29 <morcos> instagibbs: Just wanted to jot down some of the thoughts on future improvements to bumpfee
1562017-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)
1572017-07-05T19:12:02 <morcos> I think there are several reasons for this
1582017-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
1592017-07-05T19:12:52 <instagibbs> yes, rhavar brought this up on the mailing list recently
1602017-07-05T19:13:07 <instagibbs> someone does a mega-sweep on top, even low fee, and you can pay lots
1612017-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
1622017-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
1632017-07-05T19:15:00 <morcos> We should probably write up a plan for the next step in improving bumpfee functionality
1642017-07-05T19:15:24 *** talmai has quit IRC
1652017-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
1662017-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?
1672017-07-05T19:17:14 <instagibbs> Are you saying the local logic cares that downstream someone double-counted payments?
1682017-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
1692017-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
1702017-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
1712017-07-05T19:19:25 <instagibbs> I'm not grokking tbh, I might need specific examples of what's wrong here
1722017-07-05T19:19:51 <sipa> the requirement of strictly larger fee on replacement is not actually necessary to make the economics work out
1732017-07-05T19:20:34 <morcos> sipa: hmmmm.... i'm not sure that's completely correct
1742017-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
1752017-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
1762017-07-05T19:21:45 <morcos> it is a slightly broken relationship to be sure
1772017-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
1782017-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"?
1792017-07-05T19:22:59 <instagibbs> s/behavior/example
1802017-07-05T19:23:18 *** abpa has joined #bitcoin-core-dev
1812017-07-05T19:23:26 <morcos> sipa: certainly it's also not clear that would be in the best interest of miners
1822017-07-05T19:24:55 <morcos> instagibbs: let me think for a min
1832017-07-05T19:25:46 <sipa> morcos: i what way wouldn't it?
1842017-07-05T19:28:46 <morcos> sipa: hmm.. i suppose only if blocks aren't full (hopeful smiley face)
1852017-07-05T19:29:20 <morcos> but no, not even exactly that
1862017-07-05T19:29:42 <morcos> if the feerates in question are all above average, then miners have lost right?
1872017-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?
1882017-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?
1892017-07-05T19:32:27 *** Dyaheon has quit IRC
1902017-07-05T19:32:40 *** rhavar has joined #bitcoin-core-dev
1912017-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
1922017-07-05T19:33:09 <morcos> i think i agree that it should not have issues
1932017-07-05T19:33:17 <instagibbs> it'se self-invalidating
1942017-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
1952017-07-05T19:33:37 <morcos> but i agree we should be able to make it work
1962017-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
1972017-07-05T19:34:23 *** Dyaheon has joined #bitcoin-core-dev
1982017-07-05T19:34:25 <morcos> yes, so i think we can handle 1.
1992017-07-05T19:34:43 <sipa> morcos: right, ok, i'm assuming a more rational market than currently exists, i guess
2002017-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
2012017-07-05T19:35:51 <morcos> volatile != irrational does it?
2022017-07-05T19:36:26 <morcos> instagibbs: but i agree we should separate those into two separate cases... and handling all yours first seems easier
2032017-07-05T19:37:01 <sipa> morcos: i'm assuming near infinite demand at various fee rate levels
2042017-07-05T19:37:14 <sipa> reality is much more complicated, i agree
2052017-07-05T19:37:22 <rhavar> There's minor privacy implications of doing that automatically, you clearly identify which descendants are yours
2062017-07-05T19:37:26 <morcos> instagibbs: see this https://github.com/bitcoin/bitcoin/pull/8456#issuecomment-264734557 for background
2072017-07-05T19:38:00 <morcos> rhavar: you mean of only having the ability to do it when all are yours?
2082017-07-05T19:38:40 <rhavar> yeah
2092017-07-05T19:39:27 *** Murch has joined #bitcoin-core-dev
2102017-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?
2112017-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
2122017-07-05T19:39:58 <instagibbs> rhavar, no just simple bump case
2132017-07-05T19:40:25 <rhavar> oh, never mind then
2142017-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
2152017-07-05T19:40:48 <rhavar> That's not often a sane thing to do, as the fee rates will differ
2162017-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)
2172017-07-05T19:42:12 <morcos> and now we have to start looking at stuff in a per wallet world
2182017-07-05T19:42:18 <morcos> from you has to mean from this wallet
2192017-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
2202017-07-05T19:43:14 <morcos> did people envision overlapping wallets?
2212017-07-05T19:43:26 <BlueMatt> lol, morcos writes out "smiley face"
2222017-07-05T19:43:36 *** CubicEarth has joined #bitcoin-core-dev
2232017-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)
2242017-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)
2252017-07-05T19:44:46 <instagibbs> ok that cannot be replaced because we don't know fees?
2262017-07-05T19:44:59 *** chjj has quit IRC
2272017-07-05T19:45:39 <morcos> instagibbs: that's not what i meant, but maybe i'm looking at it backwards
2282017-07-05T19:45:53 <morcos> yeah i was looking at it backwards
2292017-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
2302017-07-05T19:46:22 <instagibbs> that's a check feebumper does, fwiw :P
2312017-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
2322017-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
2332017-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)
2342017-07-05T19:48:11 <rhavar> Is it really even worth while to support chains? :P
2352017-07-05T19:48:19 <morcos> so lets just forget about that (at least for now) and only bump chains of ourself
2362017-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
2372017-07-05T19:49:02 <morcos> supporting bumpng them makes a lot of sense b/c you can save money by consolidating
2382017-07-05T19:49:33 <rhavar> support bumping them. There's a lot of edge cases, like the descendant having a lower fee rate
2392017-07-05T19:49:41 <rhavar> which you might not want to consolidate
2402017-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"
2412017-07-05T19:50:29 <BlueMatt> and if there are "your" descendants, we should probably only support bumping at the bottom of the chain
2422017-07-05T19:50:56 <BlueMatt> should also probably support explicit cpfp, which handles some other cases, too
2432017-07-05T19:51:20 <morcos> BlueMatt: the advantage of not bumping at the bottom is you can consolidate
2442017-07-05T19:51:30 <morcos> you can always choose to bump at the bottom
2452017-07-05T19:51:37 <BlueMatt> well ok, but that seems like a rather separate thing, no?
2462017-07-05T19:51:51 <BlueMatt> auto-merging transactions sounds like very surprising behavior for "bumpfee"
2472017-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
2482017-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
2492017-07-05T19:52:38 <sipa> and stop seeing unconfirmed transactions as transactions
2502017-07-05T19:52:40 <BlueMatt> that sounds like reasonable behavior...for users who only need limited privacy
2512017-07-05T19:52:54 <BlueMatt> but it sounds like a separate set of RPCs?
2522017-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
2532017-07-05T19:53:28 <morcos> Let higher level software build on top of it that type of functionality
2542017-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
2552017-07-05T19:53:48 <sipa> what do you mean with limited privacy?
2562017-07-05T19:53:52 <morcos> Of course if the wallet software was separate, we could just have both
2572017-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
2582017-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
2592017-07-05T19:54:24 <sipa> it just seems so much easier to reason about
2602017-07-05T19:54:32 <BlueMatt> potentially merging outputs that they wanted to keep "separate"
2612017-07-05T19:54:52 <sipa> well this wouldn't support self-selecting inputs...
2622017-07-05T19:55:02 <BlueMatt> it doesnt, but Core does
2632017-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?
2642017-07-05T19:55:15 <BlueMatt> in the future maybe want to push people to multiwallet, but thats far away
2652017-07-05T19:55:55 <sipa> yeah, my suggestion isn't really on topic in this discussion
2662017-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.
2672017-07-05T19:56:12 <sipa> but all the reasoning about CPFP and bumping and chains of transactions makes my head hurt
2682017-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
2692017-07-05T19:56:40 <BlueMatt> morcos: maybe we should rename it "dothings" if it grows to do all kinds of magic :p
2702017-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
2712017-07-05T19:56:58 *** chjj has joined #bitcoin-core-dev
2722017-07-05T19:57:05 <BlueMatt> lol
2732017-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
2742017-07-05T19:57:13 <BlueMatt> bitcoin also wouldnt function, but thats a separate issue
2752017-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
2762017-07-05T19:57:37 <morcos> instagibbs: dynamic?
2772017-07-05T19:57:39 <instagibbs> maybe it can just get the fee wanted, but perhaps grab too many inputs in order to pay
2782017-07-05T19:57:43 <instagibbs> adding inputs for example
2792017-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
2802017-07-05T19:58:02 <instagibbs> I was really hoping to avoid doing insane loops guessing how many outputs to select
2812017-07-05T19:58:04 <BlueMatt> hmm, well maybe I take that back, maybe a list of txids is ok and not too huge
2822017-07-05T19:58:20 <morcos> instagibbs: ah, i see
2832017-07-05T19:58:24 <rhavar> the main difficulty i guess is that you'll have now multiple change addresses
2842017-07-05T19:58:31 <rhavar> but that should be easy to prune
2852017-07-05T19:58:54 <morcos> instagibbs: i would recommend just adding a new option which is payTxFeeRate
2862017-07-05T19:58:59 *** vicenteH has joined #bitcoin-core-dev
2872017-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
2882017-07-05T19:59:24 <instagibbs> and disable anything nice when using totalFee? :P
2892017-07-05T19:59:38 <morcos> No
2902017-07-05T19:59:58 <morcos> Hmm
2912017-07-05T20:00:04 <instagibbs> or just be ok grabbing too many inputs
2922017-07-05T20:00:10 * BlueMatt -> airport
2932017-07-05T20:00:11 <instagibbs> and shove the excess fee into a change output?
2942017-07-05T20:00:28 <instagibbs> (thinking along lines of using effective value)
2952017-07-05T20:00:34 <morcos> In what cases do we grab extra inputs?
2962017-07-05T20:00:48 <morcos> Only when we have no change or it's not big enough?
2972017-07-05T20:00:53 <morcos> s/do/will/
2982017-07-05T20:01:08 <instagibbs> no change or not enough yeah
2992017-07-05T20:01:23 <instagibbs> otherwise no reason to
3002017-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)
3012017-07-05T20:01:59 <rhavar> and i don't think it has any fragile and annoying logic
3022017-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
3032017-07-05T20:02:33 *** str4d has joined #bitcoin-core-dev
3042017-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.
3052017-07-05T20:03:40 <BlueMatt> morcos: yes, agreed, but you can only support consoladating at the bottom of the chain
3062017-07-05T20:04:02 <BlueMatt> if you want to consolodate mid-chain, things might break, and thats less of our issue
3072017-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
3082017-07-05T20:04:31 <morcos> Supporting it in the totalFee case (if possible) can be later.
3092017-07-05T20:04:45 <morcos> Adding a payTxFeeRate is orthogonal and as simple as above.
3102017-07-05T20:05:46 <instagibbs> morcos, if we don't have that constraint, should be a fairly simple effective value selection, no?
3112017-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.
3122017-07-05T20:06:14 <instagibbs> Fair enough, was just hoping it was a useless arg to have less code
3132017-07-05T20:06:18 <morcos> instagibbs: don't have what constraint? that it has to work with totalFee?
3142017-07-05T20:07:26 <instagibbs> Yeah. Previously it's dead-easy because you just adjust the change.
3152017-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
3162017-07-05T20:12:12 <rhavar> and then all that logic can be reused
3172017-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
3182017-07-05T20:14:21 <rhavar> so you can avoid that by only adding new inputs (at the cost of worse coin selection)
3192017-07-05T20:14:59 <instagibbs> oh please, not that rabbit hole
3202017-07-05T20:15:22 *** Murch has quit IRC
3212017-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
3222017-07-05T20:15:47 <instagibbs> right nothing in principle is wrong, just the versioning thing
3232017-07-05T20:16:04 <instagibbs> it's obviously correct, just hard
3242017-07-05T20:16:21 <morcos> instagibbs: yeah to that point, i'd argue we should concentrate on the BnB and effective value logic first
3252017-07-05T20:16:36 <instagibbs> our functionary stack uses a version of that logic to not doublespend
3262017-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
3272017-07-05T20:16:59 <instagibbs> morcos, agreed, I was building a speculative PR on top of achow's
3282017-07-05T20:18:54 <instagibbs> I'm supporting BnB as trojan horse to get effective value in (kidding, sorta)
3292017-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
3302017-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!
3312017-07-05T20:24:04 <instagibbs> gmaxwell, hopefully it doesn't cause bloat for bumpfee!
3322017-07-05T20:24:09 <instagibbs> :)
3332017-07-05T20:25:38 <instagibbs> not trying to be flippant, you can just take negative EV outputs anyways
3342017-07-05T20:25:56 *** Murch has joined #bitcoin-core-dev
3352017-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.
3362017-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.
3372017-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.
3382017-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)
3392017-07-05T20:30:38 <rhavar> hmm never mind, i'm stupid
3402017-07-05T20:30:51 *** AaronvanW has joined #bitcoin-core-dev
3412017-07-05T20:32:36 *** riemann has quit IRC
3422017-07-05T20:33:31 <instagibbs> gmaxwell, would simulations suffice? What kind of data are people looking for?
3432017-07-05T20:34:07 *** Murch has quit IRC
3442017-07-05T20:34:41 *** RubenSomsen has quit IRC
3452017-07-05T20:36:49 *** AaronvanW has quit IRC
3462017-07-05T20:40:02 *** Murch has joined #bitcoin-core-dev
3472017-07-05T20:49:57 *** talmai has joined #bitcoin-core-dev
3482017-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.
3492017-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.
3502017-07-05T21:02:56 <morcos> We're doing stupid things now by spending uneconomical inputs
3512017-07-05T21:03:16 <morcos> To fix that and prevent utxo bloat getting worse takes a more involved solution I think
3522017-07-05T21:03:32 <morcos> Being smarter about what size outputs we create is one starting point
3532017-07-05T21:03:48 <morcos> But the key is also being willing to purposefully pick multiple small outputs to consolidate sometimes
3542017-07-05T21:04:02 <morcos> The tricky thing is when to do that
3552017-07-05T21:04:05 *** str4d has quit IRC
3562017-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
3572017-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.
3582017-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.
3592017-07-05T21:06:01 <instagibbs> morcos, you can at least compare apples to apples, which might be useful
3602017-07-05T21:06:19 <morcos> Depends on what an apple is I guess
3612017-07-05T21:06:38 <morcos> but like i said, i'm all for tryingsimulations out
3622017-07-05T21:06:48 *** abpa has quit IRC
3632017-07-05T21:11:09 *** timothy has joined #bitcoin-core-dev
3642017-07-05T21:14:52 *** Murch has quit IRC
3652017-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.
3662017-07-05T21:18:00 <morcos> gmaxwell: what do you propose as an alternative?
3672017-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
3682017-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.
3692017-07-05T21:19:40 <morcos> Simulate how?
3702017-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)
3712017-07-05T21:20:24 <morcos> gmaxwell: well the "especially .." is the part i think we need to address first
3722017-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
3732017-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
3742017-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.
3752017-07-05T21:22:50 <morcos> without understanding some structure of how tx flows look, we're at risk of producing useless results
3762017-07-05T21:23:05 <gmaxwell> morcos: well murch's simulation had traces of real payment in, payment out amounts.
3772017-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
3782017-07-05T21:23:15 *** talmai has quit IRC
3792017-07-05T21:23:34 <morcos> did you read my whole spiel.. i thought we should do those other things as well
3802017-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.
3812017-07-05T21:24:02 <morcos> but it's actually easier to build those other things properly on top of an effective value framework
3822017-07-05T21:24:42 <rhavar> Has anyone suggested raising the "is dust" check to something more sane?
3832017-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.
3842017-07-05T21:24:50 <instagibbs> rhavar, yep
3852017-07-05T21:24:55 <rhavar> the current dust threshold is ludicrously low
3862017-07-05T21:25:10 <instagibbs> rhavar, the BnB branch does just that, to minimize review surface, but generally raising it is a goal too
3872017-07-05T21:25:18 *** talmai has joined #bitcoin-core-dev
3882017-07-05T21:25:21 <sipa> rhavar: using effectively output value effectively does that
3892017-07-05T21:25:25 <gmaxwell> I think rhavar is talking about something different instagibbs, sipa.
3902017-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!
3912017-07-05T21:25:31 <rhavar> i'm talking about is standard
3922017-07-05T21:25:34 <gmaxwell> rhavar is talking about what the network allows people to do.
3932017-07-05T21:25:37 <sipa> oh
3942017-07-05T21:25:39 <instagibbs> oh, then no
3952017-07-05T21:25:40 <rhavar> not the coin selection itself
3962017-07-05T21:25:55 <gmaxwell> rhavar: I think we should get rid of it, unfortunately it's ineffective since some large miners bypass it.
3972017-07-05T21:26:22 <sipa> no sane coin selection strategy should produce anything near the current dust threshold
3982017-07-05T21:26:29 <rhavar> some miners do bypass it, but it's still quite effective as a network policy
3992017-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
4002017-07-05T21:26:46 <sipa> but there are quite a few not-so-sane coin selection algorithms out there...
4012017-07-05T21:26:48 <rhavar> it stops a lot of fee attacks
4022017-07-05T21:26:53 <gmaxwell> morcos: perhaps.
4032017-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
4042017-07-05T21:27:12 <gmaxwell> rhavar: I don't think it does, you can reliably get txn mined that violate it.
4052017-07-05T21:27:29 <rhavar> if they could've spammed with 1 sat outputs, it would've been a lot more effective
4062017-07-05T21:27:43 <rhavar> and at a certain point people wouldn't even bother trying to clean it up
4072017-07-05T21:27:47 <rhavar> which leads to permanent bloat
4082017-07-05T21:28:17 <rhavar> Unless you imagine a future where spending dust has <= 0 weight :P
4092017-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.
4102017-07-05T21:28:41 <gmaxwell> Constant amounts of bloat don't concern me, bloat blowup does. :)
4112017-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.
4122017-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)
4132017-07-05T21:30:22 *** Guyver2 has quit IRC
4142017-07-05T21:30:26 <rhavar> they send to 1 peer who rejects it, so they use a higher amount
4152017-07-05T21:30:34 <gmaxwell> rhavar: why? are they just too stupid to give their txn directly to antpool?
4162017-07-05T21:30:41 <rhavar> probably
4172017-07-05T21:30:45 <gmaxwell> (or whomever else is bypassing at the moment)
4182017-07-05T21:31:01 <gmaxwell> fair but kind of a fragile justification.
4192017-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
4202017-07-05T21:31:35 <rhavar> they probably aren't aware of that some miners don't enforce
4212017-07-05T21:31:42 *** goatpig has quit IRC
4222017-07-05T21:32:51 <rhavar> it's a pretty big attack vector though, i'm not sure a sane way to deal with it
4232017-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)
4242017-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
4252017-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)
4262017-07-05T21:34:10 <rhavar> yeah i'm aware =)
4272017-07-05T21:34:17 <instagibbs> he wants infinite discount :P
4282017-07-05T21:34:23 <gmaxwell> And having wallets be sensible about not spending insanely uneconomical dust would be good.
4292017-07-05T21:34:53 <rhavar> instagibbs: nah, i want a constant negative weight for each byte you remove from the utxo :P
4302017-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. :)
4312017-07-05T21:35:15 <gmaxwell> negative weight is even more problematic than infinite discount.
4322017-07-05T21:35:17 <gmaxwell> :(
4332017-07-05T21:35:24 <sipa> just surcharge for outputs
4342017-07-05T21:35:35 <rhavar> unless you join the dark size and embrace almost unbounded size blocks 8)
4352017-07-05T21:35:51 <rhavar> (they'd still be bounded to the size of the utxo or something lolz)
4362017-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.
4372017-07-05T21:37:27 *** Chris_Stewart_5 has joined #bitcoin-core-dev
4382017-07-05T21:37:49 *** Murch has joined #bitcoin-core-dev
4392017-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
4402017-07-05T21:39:07 <sipa> short-term, terrible
4412017-07-05T21:39:10 <sipa> long-term, great
4422017-07-05T21:39:27 <rhavar> as it'd kind of be a "one off" style block, as it's obviously not sustainable
4432017-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
4442017-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"
4452017-07-05T21:40:38 <rhavar> I just meant that if you came up with a weighting scheme that made it possible
4462017-07-05T21:40:45 <sipa> rhavar: ah, i see
4472017-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).
4482017-07-05T21:41:21 <rhavar> fair point
4492017-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.
4502017-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.
4512017-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.
4522017-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.
4532017-07-05T21:43:01 <morcos> BlueMatt has a pAtent on that though, even more problematic than segwit pAtents
4542017-07-05T21:43:15 <gmaxwell> lol
4552017-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
4562017-07-05T21:43:41 *** Murch has quit IRC
4572017-07-05T21:43:48 <rhavar> although multiple limits is nasty for transaction selection :(
4582017-07-05T21:44:08 *** Murch has joined #bitcoin-core-dev
4592017-07-05T21:44:15 <rhavar> that wasn't* able to be continually hit
4602017-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.
4612017-07-05T21:45:38 <gmaxwell> In general I think anything where it can go negative immediately leads to non-trivial stratigies for income maximization.
4622017-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
4632017-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
4642017-07-05T21:47:07 <morcos> I like these changes that can be made without redoing coin selection.
4652017-07-05T21:47:09 <rhavar> it'd be impossible for the block size limit to be hit frequently
4662017-07-05T21:47:58 <morcos> It would be easy to add a new calculation. GetDiscardRate = max(dustrate, min(discardrate, estimatesmartfee(1000)))
4672017-07-05T21:48:50 <morcos> then if we configured discardrate default to something > 1 sat/Byte .
4682017-07-05T21:49:22 <morcos> i'm the king of adding new rate variables though
4692017-07-05T21:51:02 <morcos> say it was 5 sat/byte
4702017-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
4712017-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
4722017-07-05T21:53:17 <rhavar> what's the alternative though? redoing coin selection?
4732017-07-05T21:53:22 <morcos> taking the min with estimatesmartfee(1000) though helps avoid it becoming bad if BTC denominated fees
4742017-07-05T21:53:59 <morcos> drop
4752017-07-05T21:54:00 <morcos> rhavar: the problem with coin selection, is you don't know if you actually could get a better result
4762017-07-05T21:54:28 *** chjj has quit IRC
4772017-07-05T21:54:56 <rhavar> with "redoing coin selection" i mean it would contain the same logic about omitting change
4782017-07-05T21:55:58 <instagibbs> the coin selection could pick a similar sized set and get to keep the change, instead of dump it
4792017-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)
4802017-07-05T21:56:42 <rhavar> yeah, i think it's strictly better or equal (from a fee perspective, not privacy)
4812017-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
4822017-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.
4832017-07-05T21:58:30 <morcos> i'll write it up.. it's small
4842017-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.
4852017-07-05T22:00:04 <morcos> gmaxwell: but then you're throwing it away twice
4862017-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?
4872017-07-05T22:00:45 <gmaxwell> rhavar: achow101's implementation uses a 1008 block feerate estimate.
4882017-07-05T22:00:55 <gmaxwell> rhavar: as the feerate.
4892017-07-05T22:00:58 <rhavar> ah nic
4902017-07-05T22:00:59 <rhavar> e
4912017-07-05T22:01:09 <rhavar> same as my code then :D
4922017-07-05T22:01:17 <gmaxwell> morcos: I don't get the 'throwing it away twice'?
4932017-07-05T22:01:35 <BlueMatt> lol, morcos' troll game is strong today
4942017-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.
4952017-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
4962017-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
4972017-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?
4982017-07-05T22:02:19 <BlueMatt> or are you suggesting we should explicitly not support chains in your wallet without segwit (which is true)
4992017-07-05T22:02:32 <gmaxwell> morcos: ah okay, don't do that.
5002017-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)
5012017-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.
5022017-07-05T22:04:20 <BlueMatt> what do you care if the child gets confirmed?
5032017-07-05T22:04:28 <BlueMatt> great! you've saved the attempted-bump in fees?
5042017-07-05T22:04:49 <BlueMatt> now the user is a bit confused, and may need to bump the child again, but thats ok
5052017-07-05T22:07:21 *** chjj has joined #bitcoin-core-dev
5062017-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?
5072017-07-05T22:07:52 <morcos> if the bump loses, i don't think you've done too much harm to the child have you?
5082017-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.
5092017-07-05T22:10:22 <gmaxwell> Perhaps I'm talking about something a bit more broad than bluematt.
5102017-07-05T22:12:41 <BlueMatt> I believe you are talking about a very full-featured bumpfee, much more than I am thinking?
5112017-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 :(
5122017-07-05T22:13:30 *** talmai has quit IRC
5132017-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.
5142017-07-05T22:18:45 <BlueMatt> would those then get merged, or no?
5152017-07-05T22:18:48 <rhavar> yeah
5162017-07-05T22:18:57 <BlueMatt> yea, I agree, but I dont think thats an issue pre-segwit
5172017-07-05T22:19:10 <rhavar> yeah, i don't see how malleability matters at all
5182017-07-05T22:19:32 <rhavar> (at least if nothing has descendants)
5192017-07-05T22:20:14 <gmaxwell> it doesn't matter if nothing has decendants. But BlueMatt was talking about decendants, unless I've misunderstood.
5202017-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
5212017-07-05T22:20:31 <BlueMatt> i was, but I'm still confused
5222017-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
5232017-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
5242017-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.
5252017-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.
5262017-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.
5272017-07-05T22:23:33 <BlueMatt> well that has nothing to do with bumping
5282017-07-05T22:23:44 <BlueMatt> thats just the general-case spending-unconfirmed
5292017-07-05T22:24:05 <BlueMatt> and I dont see why you need to sign A'->B, you're just merging?
5302017-07-05T22:24:07 <BlueMatt> what is A'?
5312017-07-05T22:25:17 * BlueMatt -> boarding, bbl when we get off
5322017-07-05T22:29:27 <morcos> gmaxwell: take a look at the comment I linked above: https://github.com/bitcoin/bitcoin/pull/8456#issuecomment-264734557
5332017-07-05T22:29:30 <morcos> it's your comment
5342017-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
5352017-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
5362017-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
5372017-07-05T22:32:57 <gmaxwell> morcos: no, it's a problem with making a child of a transaction that has a bump.
5382017-07-05T22:33:16 <morcos> ok agreed
5392017-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.
5402017-07-05T22:34:00 *** tiagotrs has quit IRC
5412017-07-05T22:35:33 <rhavar> sounds good to me ;D
5422017-07-05T22:38:28 *** Dyaheon has quit IRC
5432017-07-05T22:39:36 *** Dyaheon has joined #bitcoin-core-dev
5442017-07-05T22:50:31 *** Evel-Knievel has quit IRC
5452017-07-05T22:59:26 *** PaulCapestany has quit IRC
5462017-07-05T23:00:44 *** chjj has quit IRC
5472017-07-05T23:01:15 *** chainhead has joined #bitcoin-core-dev
5482017-07-05T23:08:02 *** Gabo has joined #bitcoin-core-dev
5492017-07-05T23:11:20 *** Gabo has quit IRC
5502017-07-05T23:14:03 *** chjj has joined #bitcoin-core-dev
5512017-07-05T23:27:31 *** handlex has joined #bitcoin-core-dev
5522017-07-05T23:38:01 *** chjj has quit IRC
5532017-07-05T23:48:40 *** talmai has joined #bitcoin-core-dev
5542017-07-05T23:48:46 *** handlex has quit IRC
5552017-07-05T23:49:29 *** handlex has joined #bitcoin-core-dev
5562017-07-05T23:51:37 *** chjj has joined #bitcoin-core-dev
5572017-07-05T23:59:29 *** Chris_Stewart_5 has quit IRC