--- Day changed Wed Jul 05 2017
00:02 -!- goatpig [56f75436@gateway/web/freenode/ip.86.247.84.54] has joined #bitcoin-core-dev     
00:37 -!- coredump_ [~quassel@vpn-qld171.vpnsolutions.com.au] has quit [Ping timeout: 246 seconds]     
00:40 -!- laurentmt [~Thunderbi@92.154.68.134] has joined #bitcoin-core-dev     
00:46 -!- laurentmt [~Thunderbi@92.154.68.134] has quit [Quit: laurentmt]     
01:10 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
01:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 255 seconds]     
01:15 -!- schnerchi [~schnerchi@2a01:4f8:c0c:afe::2] has quit [Ping timeout: 246 seconds]     
01:21 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
01:24 -!- schnerchi [~schnerchi@static.120.187.99.88.clients.your-server.de] has joined #bitcoin-core-dev     
01:25 -!- Deadhand [~deadhand@2607:fea8:e3a0:84b::5] has quit [Ping timeout: 276 seconds]     
01:29 -!- Deadhand [~deadhand@2607:fea8:e3a0:84b::5] has joined #bitcoin-core-dev     
01:54 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev     
01:58 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-tlnghsuuuvwhxnvn] has quit [Quit: Connection closed for inactivity]     
02:11 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
02:23 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
02:26 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]     
02:30 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
03:00 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev     
03:25 -!- JackH [~laptop@46.231.18.66] has joined #bitcoin-core-dev     
03:26 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds]     
03:28 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
03:35 -!- vicenteH [~user@195.235.96.150] has joined #bitcoin-core-dev     
04:23 < 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
05:03 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection]     
05:05 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev     
05:39 -!- AaronvanW_ [~ewout@207pc74.sshunet.nl] has joined #bitcoin-core-dev     
05:45 -!- talmai [~T@c-76-24-28-74.hsd1.ma.comcast.net] has joined #bitcoin-core-dev     
06:07 -!- Guyver2_ [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
06:09 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds]     
06:09 -!- Guyver2_ is now known as Guyver2     
06:16 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 260 seconds]     
06:17 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
06:24 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
06:27 < bitcoin-git> [bitcoin] jnewbery opened pull request #10748: [config] Help text cleanup (master...helptextcleanup) https://github.com/bitcoin/bitcoin/pull/10748
06:34 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 255 seconds]     
06:43 -!- BartokIT [~BartokIT@5.90.158.186] has joined #bitcoin-core-dev     
06:47 -!- Guyver2_ [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
06:49 -!- BartokIT [~BartokIT@5.90.158.186] has quit [Ping timeout: 248 seconds]     
06:50 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds]     
06:50 -!- Guyver2_ is now known as Guyver2     
07:07 -!- Dejah [~Dejah@188.226.139.184] has joined #bitcoin-core-dev     
07:11 -!- Dejah [~Dejah@188.226.139.184] has quit [Ping timeout: 240 seconds]     
07:15 -!- talmai [~T@c-76-24-28-74.hsd1.ma.comcast.net] has quit [Ping timeout: 260 seconds]     
07:15 -!- Margarita2 [~Margarita@188.226.139.184] has joined #bitcoin-core-dev     
07:19 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
07:20 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
07:22 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 248 seconds]     
07:23 -!- echonaut [~echonaut@46.101.192.134] has quit [Remote host closed the connection]     
07:23 -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-core-dev     
07:26 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds]     
07:27 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
07:30 -!- JackH [~laptop@46.231.18.66] has quit [Quit: Leaving]     
07:34 -!- musalbas [~musalbas@2001:bc8:30c2:ff00::] has quit [Ping timeout: 255 seconds]     
07:36 -!- musalbas [~musalbas@2001:bc8:30c2:ff00::] has joined #bitcoin-core-dev     
07:40 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
07:52 < 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
07:56 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has quit [Quit: Leaving]     
08:17 -!- Guest86952 [~triplesla@173-165-23-217-Illinois.hfc.comcastbusiness.net] has quit [Remote host closed the connection]     
08:17 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev     
08:22 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds]     
08:22 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
08:31 < 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
08:46 -!- Yogaqueef [~textual@dsl-hkibng42-5673c3-32.dhcp.inet.fi] has joined #bitcoin-core-dev     
08:46 -!- Yogaqueef [~textual@dsl-hkibng42-5673c3-32.dhcp.inet.fi] has quit [Client Quit]     
09:15 -!- isis [~isis@abulafia.patternsinthevoid.net] has left #bitcoin-core-dev []     
09:36 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-jdisxrouvkpjlsqu] has joined #bitcoin-core-dev     
09:38 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 260 seconds]     
09:46 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has joined #bitcoin-core-dev     
09:51 -!- RoyceX [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Read error: Connection reset by peer]     
09:51 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev     
09:54 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
10:12 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
10:26 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 260 seconds]     
10:28 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
10:31 -!- ovovo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev     
10:33 -!- vicenteH [~user@195.235.96.150] has quit [Ping timeout: 240 seconds]     
10:34 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 240 seconds]     
10:34 -!- timothy [tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]     
10:38 < earlz> Is there a know minimum gcc version for compiling Bitcoin Core? 
10:42 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
10:43 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
10:46 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Quit: Leaving.]     
10:51 < sipa> 4.8     
10:55 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev     
11:04 -!- talmai [~T@c-76-24-28-74.hsd1.ma.comcast.net] has joined #bitcoin-core-dev     
11:11 -!- Margarita2 [~Margarita@188.226.139.184] has quit [Remote host closed the connection]     
11:14 -!- Lilly2 [~Lilly@188.226.139.184] has joined #bitcoin-core-dev     
11:27 -!- Guyver2_ [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
11:29 -!- riemann [~riemann@ip-222-88.ists.pl] has joined #bitcoin-core-dev     
11:31 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds]     
11:31 -!- Guyver2_ is now known as Guyver2     
11:38 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]     
11:39 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
11:43 < 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
11:43 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 248 seconds]     
11:54 -!- tmddzk [~tom@c-73-189-35-88.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
11:55 -!- ovovo is now known as owowo     
11:57 -!- ajd__ [~Anthony@91.239.96.138] has quit [Quit: Leaving]     
12:02 -!- Yogaqueef [~textual@dsl-hkibng42-5673c3-32.dhcp.inet.fi] has joined #bitcoin-core-dev     
12:08 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev     
12:11 < morcos> instagibbs: Just wanted to jot down some of the thoughts on future improvements to bumpfee
12:11 < 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)
12:12 < morcos> I think there are several reasons for this
12:12 < morcos> One you might unintentionally pay way more in fee than you were expecting b/c you're paying for a lot of descendants
12:12 < instagibbs> yes, rhavar brought this up on the mailing list recently
12:13 < instagibbs> someone does a mega-sweep on top, even low fee, and you can pay lots
12:13 < morcos> Two is the tricky issue of you aren't sure which transaction is actually going to get confirmed, the original or the replacement
12:14 < 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
12:15 < morcos> We should probably write up a plan for the next step in improving bumpfee functionality
12:15 -!- talmai [~T@c-76-24-28-74.hsd1.ma.comcast.net] has quit [Quit: mining]     
12:15 < 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
12:17 < 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?
12:17 < instagibbs> Are you saying the local logic cares that downstream someone double-counted payments?
12:18 < 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
12:19 < 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
12:19 < 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
12:19 < instagibbs> I'm not grokking tbh, I might need specific examples of what's wrong here
12:19 < sipa> the requirement of strictly larger fee on replacement is not actually necessary to make the economics work out
12:20 < morcos> sipa: hmmmm....  i'm not sure that's completely correct
12:21 < 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
12:21 < 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
12:21 < morcos> it is a slightly broken relationship to be sure
12:22 < 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
12:22 < 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"?
12:22 < instagibbs>  s/behavior/example
12:23 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
12:23 < morcos> sipa: certainly it's also not clear that would be in the best interest of miners
12:24 < morcos> instagibbs: let me think for a min
12:25 < sipa> morcos: i what way wouldn't it?
12:28 < morcos> sipa: hmm..  i suppose only if blocks aren't full  (hopeful smiley face)
12:29 < morcos> but no, not even exactly that
12:29 < morcos> if the feerates in question are all above average, then miners have lost right?
12:30 < 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?
12:31 < morcos> if the feerate at the bottom of a block ever drops below 100 sat/B then miners lost out didn't they?
12:32 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds]     
12:32 -!- rhavar [uid237883@gateway/web/irccloud.com/x-vqidzwadevfnsdma] has joined #bitcoin-core-dev     
12:32 < 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
12:33 < morcos> i think i agree that it should not have issues
12:33 < instagibbs> it'se self-invalidating
12:33 < 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
12:33 < morcos> but i agree we should be able to make it work
12:33 < instagibbs> i think for descendants in mempool, the two easiest cases to think about: 1) all yours 2) none of yours
12:34 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
12:34 < morcos> yes, so i think we can handle 1.
12:34 < sipa> morcos: right, ok, i'm assuming a more rational market than currently exists, i guess
12:34 < 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
12:35 < morcos> volatile != irrational does it?
12:36 < morcos> instagibbs: but i agree we should separate those into two separate cases...  and handling all yours first seems easier
12:37 < sipa> morcos: i'm assuming near infinite demand at various fee rate levels
12:37 < sipa> reality is much more complicated, i agree
12:37 < rhavar> There's minor privacy implications of doing that automatically, you clearly identify which descendants are yours
12:37 < morcos> instagibbs: see this https://github.com/bitcoin/bitcoin/pull/8456#issuecomment-264734557 for background
12:38 < morcos> rhavar: you mean of only having the ability to do it when all are yours?
12:38 < rhavar> yeah
12:39 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
12:39 < 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? 
12:39 < 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
12:39 < instagibbs> rhavar, no just simple bump case
12:40 < rhavar> oh, never mind then
12:40 < 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
12:40 < rhavar> That's not often a sane thing to do, as the fee rates will differ
12: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)
12:42 < morcos> and now we have to start looking at stuff in a per wallet world
12:42 < morcos> from you has to mean from this wallet
12:43 < 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
12:43 < morcos> did people envision overlapping wallets?
12:43 < BlueMatt> lol, morcos writes out "smiley face"
12:43 -!- CubicEarth [~cubiceart@c-67-168-4-85.hsd1.wa.comcast.net] has joined #bitcoin-core-dev     
12:43 < 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)
12:44 < morcos> instagibbs: mixed tx = tx which spends some of your inputs and some of someone elses  (can't remember exactly what we call those)
12:44 < instagibbs> ok that cannot be replaced because we don't know fees?
12:44 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 255 seconds]     
12:45 < morcos> instagibbs: that's not what i meant, but maybe i'm looking at it backwards
12:45 < morcos> yeah i was looking at it backwards
12:46 < 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
12:46 < instagibbs> that's a check feebumper does, fwiw :P
12:46 < morcos> we do that in our own wallet by making sure we conflict at least one of the inputs between the two txs
12:47 < 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
12:47 < 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)
12:48 < rhavar> Is it really even worth while to support chains? :P
12:48 < morcos> so lets just forget about that (at least for now) and only bump chains of ourself
12:48 < morcos> support bumping them or support them?  unfortunately supporting them is a long lost cause, but i do think that is still valuable
12:49 < morcos> supporting bumpng them makes a lot of sense b/c you can save money by consolidating
12:49 < rhavar> support bumping them. There's a lot of edge cases, like the descendant having a lower fee rate
12:49 < rhavar> which you might not want to consolidate
12:50  * BlueMatt still votes for "you cant bump if there are not-yours descendants, without a force flag, which is mostly-unsupported"
12:50 < BlueMatt> and if there are "your" descendants, we should probably only support bumping at the bottom of the chain
12:50 < BlueMatt> should also probably support explicit cpfp, which handles some other cases, too
12:51 < morcos> BlueMatt: the advantage of not bumping at the bottom is you can consolidate
12:51 < morcos> you can always choose to bump at the bottom
12:51 < BlueMatt> well ok, but that seems like a rather separate thing, no?
12:51 < BlueMatt> auto-merging transactions sounds like very surprising behavior for "bumpfee"
12:52 < 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
12:52 < 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
12:52 < sipa> and stop seeing unconfirmed transactions as transactions
12:52 < BlueMatt> that sounds like reasonable behavior...for users who only need limited privacy
12:52 < BlueMatt> but it sounds like a separate set of RPCs?
12:53 < 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
12:53 < morcos> Let higher level software build on top of it that type of functionality
12:53 < sipa> BlueMatt: yeah, it'd need to be separate... and not compatible with any receiver that wants a txid ahead of time etc
12:53 < sipa> what do you mean with limited privacy?
12:53 < morcos> Of course if the wallet software was separate, we could just have both
12:54 < sipa> morcos: right, perhaps this is more something for a new wallet rather than an add-on to the existing one
12:54 < 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
12:54 < sipa> it just seems so much easier to reason about
12:54 < BlueMatt> potentially merging outputs that they wanted to keep "separate"
12:54 < sipa> well this wouldn't support self-selecting inputs...
12:55 < BlueMatt> it doesnt, but Core does
12:55 < rhavar> If merging was desired, wouldn't it be better to have done that in the first place when sending the 2nd transaction?
12:55 < BlueMatt> in the future maybe want to push people to multiwallet, but thats far away
12:55 < sipa> yeah, my suggestion isn't really on topic in this discussion
12:56 < 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.
12:56 < sipa> but all the reasoning about CPFP and bumping and chains of transactions makes my head hurt
12:56 < sipa> and i think there is a possible way of how things could have worked if not for legacy, that is much easier
12:56 < BlueMatt> morcos: maybe we should rename it "dothings" if it grows to do all kinds of magic :p
12:56 < morcos> if blocks were bigger and came every 10 secs instead of every 10 mins, we wouldn't really have these problems
12:56 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
12:57 < BlueMatt> lol     
12:57 < 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
12:57 < BlueMatt> bitcoin also wouldnt function, but thats a separate issue
12:57 < instagibbs> getting back to my original thing: absolute fee argument is brittle if we want to do anything dynamic with our replacements
12:57 < morcos> instagibbs: dynamic?
12:57 < instagibbs> maybe it can just get the fee wanted, but perhaps grab too many inputs in order to pay
12:57 < instagibbs> adding inputs for example
12:57 < 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
12:58 < instagibbs> I was really hoping to avoid doing insane loops guessing how many outputs to select
12:58 < BlueMatt> hmm, well maybe I take that back, maybe a list of txids is ok and not too huge
12:58 < morcos> instagibbs: ah, i see
12:58 < rhavar> the main difficulty i guess is that you'll have now multiple change addresses 
12:58 < rhavar> but that should be easy to prune
12:58 < morcos> instagibbs: i would recommend just adding a new option which is payTxFeeRate
12:58 -!- vicenteH [~user@135.234.15.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
12:59 < 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
12:59 < instagibbs> and disable anything nice when using totalFee? :P
12:59 < morcos> No     
12:59 < morcos> Hmm     
13:00 < instagibbs> or just be ok grabbing too many inputs
13:00  * BlueMatt -> airport
13:00 < instagibbs> and shove the excess fee into a change output?
13:00 < instagibbs> (thinking along lines of using effective value)
13:00 < morcos> In what cases do we grab extra inputs?
13:00 < morcos> Only when we have no change or it's not big enough?
13:00 < morcos> s/do/will/
13:01 < instagibbs> no change or not enough yeah
13:01 < instagibbs> otherwise no reason to
13:01 < 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)
13:01 < rhavar> and i don't think it has any fragile and annoying logic
13:02 < 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
13:02 -!- str4d [~str4d@pool-72-93-11-41.bstnma.east.verizon.net] has joined #bitcoin-core-dev     
13:03 < morcos> instagibbs: Yeah I think that gets tricky.  It's actually going to get a bit tricky even without thinking about totalFee, I think.
13:03 < BlueMatt> morcos: yes, agreed, but you can only support consoladating at the bottom of the chain
13:04 < BlueMatt> if you want to consolodate mid-chain, things might break, and thats less of our issue
13:04 < 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
13:04 < morcos> Supporting it in the totalFee case (if possible) can be later.
13:04 < morcos> Adding a payTxFeeRate is orthogonal and as simple as above.
13:05 < instagibbs> morcos, if we don't have that constraint, should be a fairly simple effective value selection, no?
13:05 < 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.
13:06 < instagibbs> Fair enough, was just hoping it was a useless arg to have less code
13:06 < morcos> instagibbs: don't have what constraint?  that it has to work with totalFee?
13:07 < instagibbs> Yeah. Previously it's dead-easy because you just adjust the change.
13:12 < 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
13:12 < rhavar> and then all that logic can be reused
13:13 < 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
13:14 < rhavar> so you can avoid that by only adding new inputs  (at the cost of worse coin selection)
13:14 < instagibbs> oh please, not that rabbit hole
13:15 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
13:15 < 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
13:15 < instagibbs> right nothing in principle is wrong, just the versioning thing
13:16 < instagibbs> it's obviously correct, just hard
13:16 < morcos> instagibbs: yeah to that point, i'd argue we should concentrate on the BnB and effective value logic first
13:16 < instagibbs> our functionary stack uses a version of that logic to not doublespend
13:16 < 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
13:16 < instagibbs> morcos, agreed, I was building a speculative PR on top of achow's 
13:18 < instagibbs> I'm supporting BnB as trojan horse to get effective value in (kidding, sorta)
13:20 < 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
13:23 < gmaxwell> instagibbs: you keep complaining about EV but it doesn't seem like anyone is working to fix the bloat concern!
13:24 < instagibbs> gmaxwell, hopefully it doesn't cause bloat for bumpfee!
13:24 < instagibbs> :)     
13:25 < instagibbs> not trying to be flippant, you can just take negative EV outputs anyways
13:25 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
13:26 < 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.
13:27 < 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. 
13:28 < gmaxwell> BlueMatt: we can't really do the multiple txn bump and auto-merge without segwit, I think.  Handling malleability is too gnarly.
13:29 < 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) 
13:30 < rhavar> hmm never mind, i'm stupid
13:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
13:32 -!- riemann [~riemann@ip-222-88.ists.pl] has quit [Quit: Leaving]     
13:33 < instagibbs> gmaxwell, would simulations suffice? What kind of data are people looking for?
13:34 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Read error: Connection reset by peer]     
13:34 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Ping timeout: 248 seconds]     
13:36 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
13:40 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
13:49 -!- talmai [~T@c-24-147-97-55.hsd1.ma.comcast.net] has joined #bitcoin-core-dev     
13:51 < 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. 
14:02 < 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.
14:02 < morcos> We're doing stupid things now by spending uneconomical inputs
14:03 < morcos> To fix that and prevent utxo bloat getting worse takes a more involved solution I think
14:03 < morcos> Being smarter about what size outputs we create is one starting point
14:03 < morcos> But the key is also being willing to purposefully pick multiple small outputs to consolidate sometimes
14:04 < morcos> The tricky thing is when to do that
14:04 -!- str4d [~str4d@pool-72-93-11-41.bstnma.east.verizon.net] has quit [Ping timeout: 240 seconds]     
14:04 < 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
14:05 < 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.
14:05 < morcos> Simulations are just so hard when we don't have a good sense of what the user population looks like.
14:06 < instagibbs> morcos, you can at least compare apples to apples, which might be useful
14:06 < morcos> Depends on what an apple is I guess
14:06 < morcos> but like i said, i'm all for tryingsimulations out
14:06 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com]     
14:11 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
14:11 -!- timothy [~tredaelli@redhat/timothy] has quit [Client Quit]     
14:14 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Ping timeout: 276 seconds]     
14:17 < 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.
14:18 < morcos> gmaxwell: what do you propose as an alternative?
14:18 < 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
14:19 < 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.
14:19 < morcos> Simulate how?
14:19 < 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)
14:20 < morcos> gmaxwell: well the "especially .." is the part i think we need to address first
14:21 < morcos> the problems i have with simulation is they tend to simulate over a single large wallet making and receiving a series of txs
14:22 < 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
14:22 < 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.
14:22 < morcos> without understanding some structure of how tx flows look, we're at risk of producing useless results
14:23 < gmaxwell> morcos: well murch's simulation had traces of real payment in, payment out amounts.
14:23 < 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
14:23 -!- talmai [~T@c-24-147-97-55.hsd1.ma.comcast.net] has quit [Quit: mining]     
14:23 < morcos> did you read my whole spiel..  i thought we should do those other things as well
14:23 < 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.
14:24 < morcos> but it's actually easier to build those other things properly on top of an effective value framework
14:24 < rhavar> Has anyone suggested raising the "is dust" check to something more sane? 
14:24 < 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.
14:24 < instagibbs> rhavar, yep
14:24 < rhavar> the current dust threshold is ludicrously low 
14:25 < instagibbs> rhavar, the BnB branch does just that, to minimize review surface, but generally raising it is a goal too
14:25 -!- talmai [~T@c-24-147-97-55.hsd1.ma.comcast.net] has joined #bitcoin-core-dev     
14:25 < sipa> rhavar: using effectively output value effectively does that
14:25 < gmaxwell> I think rhavar is talking about something different instagibbs, sipa.
14:25 < morcos> rhavar: yeah, changing dust levels is a bit annoying, but changing the levels at which we'll create dust is a no-brainer!
14:25 < rhavar> i'm talking about is standard
14:25 < gmaxwell> rhavar is talking about what the network allows people to do.
14:25 < sipa> oh     
14:25 < instagibbs> oh, then no
14:25 < rhavar> not the coin selection itself
14:25 < gmaxwell> rhavar: I think we should get rid of it, unfortunately it's ineffective since some large miners bypass it.
14:26 < sipa> no sane coin selection strategy should produce anything near the current dust threshold
14:26 < rhavar> some miners do bypass it, but it's still quite effective as a network policy
14:26 < 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
14:26 < sipa> but there are quite a few not-so-sane coin selection algorithms out there...
14:26 < rhavar> it stops a lot of fee attacks
14:26 < gmaxwell> morcos: perhaps. 
14:27 < 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
14:27 < gmaxwell> rhavar: I don't think it does, you can reliably get txn mined that violate it.
14:27 < rhavar> if they could've spammed with 1 sat outputs, it would've been a lot more effective
14:27 < rhavar> and at a certain point people wouldn't even bother trying to clean it up
14:27 < rhavar> which leads to permanent bloat
14:28 < 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.
14:28 < rhavar> Unless you imagine a future where spending dust has  <=  0 weight :P
14:28 < gmaxwell> Constant amounts of bloat don't concern me, bloat blowup does. :)
14:29 < 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.
14:30 < rhavar> it's also reasonably effective at stopping spammers (who are trying to attack a specific wallet, not the network itself) 
14:30 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]     
14:30 < rhavar> they send to 1 peer who rejects it, so they use a higher amount
14:30 < gmaxwell> rhavar: why? are they just too stupid to give their txn directly to antpool?
14:30 < rhavar> probably
14:30 < gmaxwell> (or whomever else is bypassing at the moment)
14:31 < gmaxwell> fair but kind of a fragile justification.
14:31 < rhavar> not sure how they even construct the spam, tbh. it's possible they just use a wallet (like core?) that rejects it immediately 
14:31 < rhavar> they probably aren't aware of that some miners don't enforce 
14:31 -!- goatpig [56f75436@gateway/web/freenode/ip.86.247.84.54] has quit [Quit: Page closed]     
14:32 < rhavar> it's a pretty big attack vector though, i'm not sure a sane way to deal with it
14:33 < 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)
14:33 < 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
14:33 < 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)
14:34 < rhavar> yeah i'm aware =)
14:34 < instagibbs> he wants infinite discount :P
14:34 < gmaxwell> And having wallets be sensible about not spending insanely uneconomical dust would be good.
14:34 < rhavar> instagibbs: nah, i want a constant negative weight for each byte you remove from the utxo    :P
14:35 < 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. :)
14:35 < gmaxwell> negative weight is even more problematic than infinite discount.
14:35 < gmaxwell> :(     
14:35 < sipa> just surcharge for outputs
14:35 < rhavar> unless you join the dark size and embrace almost unbounded size blocks 8)
14:35 < rhavar> (they'd still be bounded to the size of the utxo or something lolz)
14:35 < 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.
14:37 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
14:37 -!- Murch [~murch@mobile-166-171-248-234.mycingular.net] has joined #bitcoin-core-dev     
14:38 < rhavar> I wonder how harmful it really would be if someone mined a 1GB block that also removed 1GB from the utxo :P
14:39 < sipa> short-term, terrible
14:39 < sipa> long-term, great
14:39 < rhavar> as it'd kind of be a "one off" style block, as it's obviously not sustainable
14:40 < 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
14:40 < 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"
14:40 < rhavar> I just meant that if you came up with a weighting scheme that made it possible
14:40 < sipa> rhavar: ah, i see
14:40 < 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).
14:41 < rhavar> fair point
14:41 < 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. 
14:41 < 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. 
14:42 < gmaxwell> yea, with a HF we could go a bit further than segwit. E.g. counting the txin:vout data like witness data.
14:42 < 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.
14:43 < morcos> BlueMatt has a pAtent on that though, even more problematic than segwit pAtents
14:43 < gmaxwell> lol     
14:43 < 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
14:43 -!- Murch [~murch@mobile-166-171-248-234.mycingular.net] has quit [Ping timeout: 246 seconds]     
14:43 < rhavar> although multiple limits is nasty for transaction selection :(
14:44 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
14:44 < rhavar> that wasn't* able to be continually hit
14:45 < 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.
14:45 < gmaxwell> In general I think anything where it can go negative immediately leads to non-trivial stratigies for income maximization. 
14:46 < 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
14:47 < 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   
14:47 < morcos> I like these changes that can be made without redoing coin selection.
14:47 < rhavar> it'd be impossible for the block size limit to be hit frequently 
14:47 < morcos> It would be easy to add a new calculation.  GetDiscardRate  =  max(dustrate, min(discardrate, estimatesmartfee(1000)))
14:48 < morcos> then if we configured discardrate default to something > 1 sat/Byte .  
14:49 < morcos> i'm the king of adding new rate variables though
14:51 < morcos> say it was 5 sat/byte
14:51 < 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
14:52 < 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
14:53 < rhavar> what's the alternative though? redoing coin selection? 
14:53 < morcos> taking the min with estimatesmartfee(1000) though helps avoid it becoming bad if BTC denominated fees
14:53 < morcos> drop
14:54 < morcos> rhavar: the problem with coin selection, is you don't know if you actually could get a better result
14:54 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds]     
14:54 < rhavar> with "redoing coin selection" i mean it would contain the same logic about omitting change
14:55 < instagibbs> the coin selection could pick a similar sized set and get to keep the change, instead of dump it
14:56 < 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)
14:56 < rhavar> yeah, i think it's strictly better or equal (from a fee perspective, not privacy) 
14:57 < 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
14:57 < 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.
14:58 < morcos> i'll write it up.. it's small
14:59 < gmaxwell> morcos: you could use the BNB hurestic: you can throw away up to the cost of creating and spending the change output.
15:00 < morcos> gmaxwell: but then you're throwing it away twice
15:00 < rhavar> "spending the change output"  how does it know the cost of spending the output? At what fee rate does it use?
15:00 < gmaxwell> rhavar: achow101's implementation uses a 1008 block feerate estimate.
15:00 < gmaxwell> rhavar: as the feerate. 
15:00 < rhavar> ah nic
15:00 < rhavar> e     
15:01 < rhavar> same as my code then :D
15:01 < gmaxwell> morcos: I don't get the 'throwing it away twice'?
15:01 < BlueMatt> lol, morcos' troll game is strong today
15:01 < instagibbs> We should never be keeping change that doesn't hit that threshold, the real Q is larger but still not great. 
15:01 < 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
15:02 < 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
15:02 < 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?
15:02 < BlueMatt> or are you suggesting we should explicitly not support chains in your wallet without segwit (which is true)
15:02 < gmaxwell> morcos: ah okay, don't do that.
15:03 < 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)
15:04 < 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.
15:04 < BlueMatt> what do you care if the child gets confirmed?
15:04 < BlueMatt> great! you've saved the attempted-bump in fees?
15:04 < BlueMatt> now the user is a bit confused, and may need to bump the child again, but thats ok
15:07 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
15:07 < 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?
15:07 < morcos> if the bump loses, i don't think you've done too much harm to the child have you?
15:09 < gmaxwell> When you create a _new_ child or a _new_ bump that adds outputs, you must also make children of all the existing ones.
15:10 < gmaxwell> Perhaps I'm talking about something a bit more broad than bluematt.
15:12 < BlueMatt> I believe you are talking about a very full-featured bumpfee, much more than I am thinking?
15:12 < BlueMatt> Though I missed some of the above discussion, just waiting for them to reopen the airport after they closed it due to weather :(
15:13 -!- talmai [~T@c-24-147-97-55.hsd1.ma.comcast.net] has quit [Quit: mining]     
15:18 < 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. 
15:18 < BlueMatt> would those then get merged, or no?
15:18 < rhavar> yeah
15:18 < BlueMatt> yea, I agree, but I dont think thats an issue pre-segwit
15:19 < rhavar> yeah, i don't see how malleability matters at all
15:19 < rhavar> (at least if nothing has descendants) 
15:20 < gmaxwell> it doesn't matter if nothing has decendants. But BlueMatt was talking about decendants, unless I've misunderstood.
15:20  * 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
15:20 < BlueMatt> i was, but I'm still confused
15:21 < 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
15:21 < 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
15:21 < 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.  
15:22 < 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.
15:23 < 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. 
15:23 < BlueMatt> well that has nothing to do with bumping
15:23 < BlueMatt> thats just the general-case spending-unconfirmed
15:24 < BlueMatt> and I dont see why you need to sign A'->B, you're just merging?
15:24 < BlueMatt> what is A'?
15:25  * BlueMatt -> boarding, bbl when we get off
15:29 < morcos> gmaxwell: take a look at the comment I linked above: https://github.com/bitcoin/bitcoin/pull/8456#issuecomment-264734557
15:29 < morcos> it's your comment
15:30 < 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
15:30 < 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
15:31 < 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
15:32 < gmaxwell> morcos: no, it's a problem with making a child of a transaction that has a bump.
15:33 < morcos> ok agreed
15:33 < 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.
15:34 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has quit [Quit: leaving]     
15:35 < rhavar> sounds good to me ;D
15:38 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 258 seconds]     
15:39 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
15:50 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit [Read error: Connection reset by peer]     
15:59 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has quit [Quit: .]     
16:00 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 255 seconds]     
16:01 -!- chainhead [~chainhead@2001:19f0:5:e14:5400:ff:fe77:e3d4] has joined #bitcoin-core-dev     
16:08 -!- Gabo [~Gabo@cust-132-229-109-94.dyn.as47377.net] has joined #bitcoin-core-dev     
16:11 -!- Gabo [~Gabo@cust-132-229-109-94.dyn.as47377.net] has quit [Remote host closed the connection]     
16:14 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
16:27 -!- handlex [~handlex@179.191.106.154] has joined #bitcoin-core-dev     
16:38 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 246 seconds]     
16:48 -!- talmai [~T@c-24-147-97-55.hsd1.ma.comcast.net] has joined #bitcoin-core-dev     
16:48 -!- handlex [~handlex@179.191.106.154] has quit [Quit: handlex]     
16:49 -!- handlex [~handlex@179.191.106.154] has joined #bitcoin-core-dev     
16:51 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
16:59 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds]     
17:12 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 258 seconds]     
17:14 -!- coredump_ [~quassel@vpn-qld171.vpnsolutions.com.au] has joined #bitcoin-core-dev     
17:15 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
17:16 -!- tmddzk [~tom@c-73-189-35-88.hsd1.ca.comcast.net] has quit [Quit: Lost terminal]     
17:17 -!- owowo [ovovo@gateway/vpn/mullvad/x-ejxryjtfszumjmgm] has joined #bitcoin-core-dev     
17:18 -!- AaronvanW_ [~ewout@207pc74.sshunet.nl] has quit [Ping timeout: 240 seconds]     
17:31 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has joined #bitcoin-core-dev     
17:35 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has quit [Quit: .]     
17:44 -!- CubicEarth [~cubiceart@c-67-168-4-85.hsd1.wa.comcast.net] has quit []     
17:44 < kanzure> i am unsure of the interactions between MIN_FINAL_CHANGE and the targeted fee rate and whether that should be the assumed fee rate for eventually spending the change output.
17:48 < kanzure> oh, "achow101's implementation uses a 1008 block feerate estimate" for the change output amount check before decide burn to miner fee?
17:49 < achow101> kanzure: the 1008 block feerate estimate is for the cost of change. It's the maximum of the feerate and the min relay fee
17:50 < kanzure> "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" <--- why not redo the final size estimate and calculate new fee, then redo coin selection for potentially fewer inputs? keep list of n best options, break after grinding for i dunno 10k rounds.
17:51 < gmaxwell> because complex hairball.
17:51 < gmaxwell> Achow's stuff doesn't have that issue, the branch and bound thing assumes always that there will be no change.
17:51 < kanzure> is there a writeup of a wishlist for simulators in this area, or is that also hairball land?
17:52 < kanzure> there was already some area in core that attempts to redo coin selection by increasing the amount and trying again; some of this could probably be consolidated.
17:56 < kanzure> i have this weird case where i have to use two "change" outputs, one of them i can burn to miner fee if it's too small, the other one i need to go back and pick other inputs until i can piggyback.  anyway, lots of questions around utxo results after actual usage, i will have to write a simulator at some point.
17:58 -!- handlex [~handlex@179.191.106.154] has quit [Quit: handlex]     
17:59 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev     
18:00 < kanzure> (can't help but think of this like iterative rocket equation calculation until elon musk is sure that his rocket will land at zero velocity with zero fuel left, except for coins we're not targeting total fee exhaustion of course.)
18:05 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-jdisxrouvkpjlsqu] has quit [Quit: Connection closed for inactivity]     
18:06 -!- talmai [~T@c-24-147-97-55.hsd1.ma.comcast.net] has quit [Quit: mining]     
18:09 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 255 seconds]     
18:10 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
18:21 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
18:34 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev     
18:37 < fanquake> Would anyone object to #8550 going into 0.15 ?
18:37 < gribble> https://github.com/bitcoin/bitcoin/issues/8550 | [Qt] Add interactive mempool graph by jonasschnelli · Pull Request #8550 · bitcoin/bitcoin · GitHub
18:43 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 268 seconds]     
18:44 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
18:45 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]     
18:47 < gmaxwell> :(     
18:47 < gmaxwell> Thats the graph that doesn't break things up by feerate?
18:47 < gmaxwell> those sorts of graphs have had really bad effects in social media.
18:48 < gmaxwell> People flood with minrelay fee txn to push the numbers up. and then spam with OMG MEMPOOL FULL SELL BITCOINS NOW
18:48 < gmaxwell> Since rate breaking up graphs became more common those minrelay floods seem to have stopped.
19:08 < fanquake> Well we can adjust the graph to break the txs up and display however we'd like, but I think having that info available to node operators would be a plus.
19:19 < morcos> fanquake: that PR is based on #8501 which seems like hasn't gotten work in quite some time
19:19 < gribble> https://github.com/bitcoin/bitcoin/issues/8501 | Add mempool statistics collector by jonasschnelli · Pull Request #8501 · bitcoin/bitcoin · GitHub
19:19 < morcos> in any case I don't think it's making it for 0.15 at this point
19:20 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 255 seconds]     
19:27 -!- talmai [~T@c-24-147-97-55.hsd1.ma.comcast.net] has joined #bitcoin-core-dev     
19:31 < fanquake> morcos Fair enough. Will concentrate on other PRs. Need to put aside some time to look through all your fee work.
19:52 -!- talmai [~T@c-24-147-97-55.hsd1.ma.comcast.net] has quit [Quit: mining]     
19:57 -!- arowser [~quassel@45.32.248.113] has quit [Remote host closed the connection]     
20:03 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.]     
20:04 -!- arowser [~quassel@45.32.248.113] has joined #bitcoin-core-dev     
20:04 -!- stalictite [1896bc7b@gateway/web/freenode/ip.24.150.188.123] has joined #bitcoin-core-dev     
20:20 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev     
20:46 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Ping timeout: 248 seconds]     
20:56 -!- Alina-malina [~Alina-mal@37.157.223.81] has joined #bitcoin-core-dev     
21:09 -!- mol [~IRCIdent@unaffiliated/molly] has quit [Ping timeout: 246 seconds]     
21:11 -!- molz [~IRCIdent@unaffiliated/molly] has joined #bitcoin-core-dev     
21:15 -!- stalictite [1896bc7b@gateway/web/freenode/ip.24.150.188.123] has quit [Quit: Page closed]     
22:08 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Ping timeout: 258 seconds]     
22:09 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev     
22:11 -!- pindarhk__ [sid105966@gateway/web/irccloud.com/x-hgeknyprlmwbzerc] has joined #bitcoin-core-dev     
22:17 -!- michagogo_ [uid14316@wikia/Michagogo] has joined #bitcoin-core-dev     
22:19 -!- kinlo_ [~peter@unaffiliated/kinlo] has joined #bitcoin-core-dev     
22:22 -!- pindarhk_ [sid105966@gateway/web/irccloud.com/x-xngyropbpwwdilbx] has quit [Ping timeout: 240 seconds]     
22:22 -!- michagogo [uid14316@wikia/Michagogo] has quit [Ping timeout: 240 seconds]     
22:22 -!- kinlo [~peter@unaffiliated/kinlo] has quit [Ping timeout: 240 seconds]     
22:22 -!- pindarhk__ is now known as pindarhk_     
22:22 -!- kinlo_ is now known as kinlo     
22:22 -!- michagogo_ is now known as michagogo     
22:25 -!- Lilly2 [~Lilly@188.226.139.184] has quit [Ping timeout: 260 seconds]     
22:26 -!- lifeofguenter [~lifeofgue@bnc.pro.to.co.ls] has quit [Ping timeout: 260 seconds]     
22:27 -!- lifeofguenter [~lifeofgue@bnc.pro.to.co.ls] has joined #bitcoin-core-dev     
22:27 -!- Felipe2 [~Felipe@188.226.139.184] has joined #bitcoin-core-dev     
22:31 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 260 seconds]     
22:32 -!- cryptapus_afk [~cryptapus@jupiter.osmus.org] has joined #bitcoin-core-dev     
22:32 -!- cryptapus_afk [~cryptapus@jupiter.osmus.org] has quit [Changing host]     
22:32 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
22:38 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Ping timeout: 248 seconds]     
22:41 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 248 seconds]     
22:45 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-core-dev     
22:45 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev     
22:47 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
22:48 -!- jtimon [~quassel@102.30.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
22:50 < jtimon> sipa: something seems wrong with  how can I access the CTxOut of an input with AccessByTxid(/Coin in.prevout.hash but without needing in.prevout.n?
22:51 < jtimon> I bet I'm missing something, but not sure what
22:53 < jtimon> oh, there's no in.prevout.n anymore, nevermind
22:55 < jtimon> wait...I'll think more about this, I know how to fing the PR that's relevant
22:57 -!- atroxes [~atroxes@unaffiliated/atroxes] has quit [Ping timeout: 268 seconds]     
23:02 -!- atroxes [~atroxes@unaffiliated/atroxes] has joined #bitcoin-core-dev     
23:18 -!- city22 [~textual@211.94.117.2] has joined #bitcoin-core-dev     
23:19 -!- waxwing [~waxwing@unaffiliated/waxwing] has quit [Ping timeout: 260 seconds]     
23:20 -!- MarcoFalke [~none@198.12.116.246] has quit [Ping timeout: 260 seconds]     
23:20 -!- MarcoFalke [~none@198.12.116.246] has joined #bitcoin-core-dev     
23:20 -!- waxwing [~waxwing@91.216.245.111] has joined #bitcoin-core-dev     
23:21 -!- petertodd [~pete@ec2-52-5-185-120.compute-1.amazonaws.com] has quit [Ping timeout: 260 seconds]     
23:21 -!- jnewbery [~john@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Ping timeout: 260 seconds]     
23:21 -!- jnewbery [~john@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
23:22 -!- petertodd [~pete@ec2-52-5-185-120.compute-1.amazonaws.com] has joined #bitcoin-core-dev     
23:33 < gmaxwell> jtimon: you cannot. The database doesn't efficiently support that access anymore, it shouldn't generally be needed.
23:38 < jtimon> gmaxwell: my point is...how can it even guarantee the input looked for is the one that is gotten without passing n? it seems like all instances of  AccessByTxid should be replaced wiht inputs.AccessCoin(tx.vin[n].prevout) or a similar wrapper
23:39 < jtimon> summary: AccessByTxid seems completely uinsafe to me at this point unless I'm missing something
23:39 < jtimon> which is not uncommon
23:41 -!- waxwing [~waxwing@91.216.245.111] has quit [Changing host]     
23:41 -!- waxwing [~waxwing@unaffiliated/waxwing] has joined #bitcoin-core-dev     
23:41 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-nueqomslgqulspku] has joined #bitcoin-core-dev     
23:45 -!- pigma64 [~pigma64@108-233-47-56.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev     
23:45 -!- pigma64 [~pigma64@108-233-47-56.lightspeed.sntcca.sbcglobal.net] has quit [Read error: Connection reset by peer]     
23:50 < sipa> jtimon: AccessByTxid is only for finding height/coinbase
23:50 < sipa> obviously you can't use it to find an actual output
23:52 < jtimon> oh, I see, that's what I was missing
23:52 < sipa> it's also extremely slow
23:52 < jtimon> it still seems weird that you have access to some arvitrary txout from it though
23:52 < sipa> i guess
23:53 < wumpus> please don't do anything on transifex, especially with the "0.15.x" resource, I was running the script to copy over the translation strings from 0.14 and something weird happened, not sure why but it looked like someone overwrote the translation strings (even though it's locked)
23:54 < jtimon> it shouldn't retun a full coin class, or something, anyway, thank you for the missing piece
23:55 -!- pigma64 [~pigma64@108-233-47-56.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev     
23:56 < sipa> seems very reasonable to document that
23:58 < sipa> gmaxwell: finding CTxOuts is totally doable though... you just need AccessCoin not AccessByTxid
23:59 < sipa> (Coin contains a CTxOut and fCoinbase and nHeight)