12017-01-24T00:03:40 *** abpa has joined #bitcoin-core-dev
22017-01-24T00:07:23 <Lightsword> think we can add an option to force bump fee even if opt-in RBF was not used? often transactions will relay regardless since they wouldnât already be in mempools
32017-01-24T00:12:13 <gmaxwell> Lightsword: ugh. forcing the creation of a transaction that we won't relay ourselves is .. a bit ugly. :(
42017-01-24T00:12:55 <Lightsword> gmaxwell, well it would make sense to allow ourselves to relay it as well
52017-01-24T00:13:20 <sipa> Lightsword: that is equivalent to implementing full RBF
62017-01-24T00:14:10 <sipa> and we're not going to make an exception for your own transaction, as that's a privacy leak
72017-01-24T00:14:44 *** chjj has joined #bitcoin-core-dev
82017-01-24T00:18:16 *** belcher has joined #bitcoin-core-dev
92017-01-24T00:29:07 *** e4xit has quit IRC
102017-01-24T00:30:02 *** e4xit has joined #bitcoin-core-dev
112017-01-24T00:56:09 <Lightsword> sipa, would it make sense to have it only under a force flag? Iâm mainly thinking itâs better to have the bumpfee option than having to do it manually
122017-01-24T00:58:33 *** abpa has quit IRC
132017-01-24T00:58:38 <sipa> i think the only reasonable way to do it is to first have someone use abandontransaction (which will only work if it's already evicted from the mempool), and then a wrapper to recreate an abandoned transaction with a higher fee (but guaranteeing that some if its inputs are spent again)
142017-01-24T00:58:51 <sipa> that way you don't need an exception for relay
152017-01-24T01:08:04 <luke-jr> gmaxwell: what if we would relay it ourselves because it's dropped out of our mempool?
162017-01-24T01:08:25 <luke-jr> sipa: must it be abandoned explicitly?
172017-01-24T01:09:31 <sipa> luke-jr: otherwise the wallet won't allow you to respend
182017-01-24T01:09:53 <luke-jr> sipa: bumpfee will?
192017-01-24T01:14:29 <sipa> luke-jr: bumpfee won't let you bump without it being bip125
202017-01-24T01:15:03 <sipa> or are you saying that bumpfee should do that, IF the result would be acceptable to our own mempool?
212017-01-24T01:16:31 <luke-jr> sipa: and if a "force" option is provided
222017-01-24T01:17:48 <sipa> that seems reasonable
232017-01-24T01:20:35 <Lightsword> the user can restart their node to force the transaction out of the mempool right?
242017-01-24T01:21:20 *** Kexkey has quit IRC
252017-01-24T01:22:40 <sipa> if they delete mempool.dat, yes
262017-01-24T01:26:07 *** Kexkey has joined #bitcoin-core-dev
272017-01-24T01:26:23 <Lightsword> is it possible to manually evict a transaction from the mempool by doing a negative prioritisetransaction call so it goes below the minfee needed to stay in the mempool?
282017-01-24T01:35:40 <morcos> Lightsword: I think that would only work if the mempool was full (and some other transaction came in to cause limiting)
292017-01-24T01:35:55 <morcos> however a restart combined with a negative prioritisetransaction might work
302017-01-24T01:36:24 <Lightsword> morcos, mempool is normally full with the way the limiter currently works right?
312017-01-24T01:36:38 <sipa> it won't be full shortly after a new block was found
322017-01-24T01:37:25 <morcos> it doesn't seem so recently.. and even if the network is busy it tends to not stay full b/c fee filter stops you getting cheap replacements
332017-01-24T01:39:28 <Lightsword> isnât fee filter mostly based on feerate of recently evicted transactions?
342017-01-24T01:40:20 <morcos> sipa: i'm not around next week and #9371 or otherwise is necessary for 0.14.. could you take a look and if you agree with the approach, we could at least tag the PR 0.14 and i can give someone else repo access to carry it over the finish line
352017-01-24T01:40:22 <gribble> https://github.com/bitcoin/bitcoin/issues/9371 | Notify on removal by morcos · Pull Request #9371 · bitcoin/bitcoin · GitHub
362017-01-24T01:40:35 <morcos> right now just the issue is tagged for 0.14, b/c we never agreed what type of solution we want
372017-01-24T01:41:07 <sipa> morcos: will do
382017-01-24T01:41:42 <morcos> Lightsword: yes, but the minfee which the fee filter is set to = incrementalRelayRate (same as minRelayTxFee before 0.14) + the evicted rate. in practice, this is 1000 sat/KB + 1000 sat/KB
392017-01-24T01:42:11 <morcos> therefore excluding all the garbage between 1000-2000 sat/KB which is the only way your mempool fills up
402017-01-24T01:42:41 <morcos> so until the fee rate declines below 1000 sat/KB again... your mempool tends to get less full...
412017-01-24T01:43:18 <morcos> that was at least true with 3 day time expiration... with 2 week time expiration in 0.14, your mempool might stay closer to full? depending on current tx supply
422017-01-24T01:45:07 <gmaxwell> sipa: well we could allow abandond transactions to get bumped.
432017-01-24T01:45:45 <gmaxwell> but we aren't very permissive with abandonment.
442017-01-24T01:46:13 <morcos> i think we should try as hard as possible to not ever recommend abandoning
452017-01-24T01:46:19 <morcos> not that it doens't work well
462017-01-24T01:46:42 <morcos> but i think it'll inevitably lead to people spending different outputs and having both txs confirm
472017-01-24T01:47:30 *** Ylbam has quit IRC
482017-01-24T01:47:37 <morcos> in that sense, i kind of think Lightsword is right... if you have a "stuck" transaction and you forgot to make it opt-in RBF, it's probably better to still let you bumpfee it
492017-01-24T01:48:02 <Lightsword> I think it would be a good idea to let one broadcast as well with a force flag
502017-01-24T01:48:03 <morcos> otherwise you are going to use abandontransaction and try to do it manually and end up screwing yourself
512017-01-24T01:48:12 <Lightsword> since itâs a major useability issue
522017-01-24T01:48:19 <sipa> gmaxwell: i think what luke is suggesting is allowing /abandonable/ transactions to be bumped
532017-01-24T01:49:12 <sipa> i do think that's better... first fully abandoning them would perhaps introduce a race conditions where you respend the coins in between the abandon and the bump
542017-01-24T01:49:16 <gmaxwell> I think thats reasonable, but the set of abandonable transactions is so small as to make it hardly matter.
552017-01-24T01:49:41 <sipa> evicted from mempool is enough, no?
562017-01-24T01:50:10 <morcos> but that's basically not going to happen, unless you finagle it, and if you're going to finagle it, well why not just let you do it anyway
572017-01-24T01:50:19 <morcos> whats the downside, privacy leak?
582017-01-24T01:52:08 <gmaxwell> sipa: what morcos said.
592017-01-24T01:52:40 <sipa> is it reasonable to expect your transaction will propagate otherwise?
602017-01-24T01:52:57 <sipa> i would expect relatively similar mempool among your peers
612017-01-24T01:53:01 <gmaxwell> the major downside is that we'll end up with txn in our wallet that we don't expect to relay, which is something we kind of assume doesn't happen.
622017-01-24T01:53:28 <gmaxwell> sipa: well except peers change over time, so maybe not. or you might have a full rbf peer.
632017-01-24T01:53:50 <morcos> or you might want to construct a tx to submit in some out of band way to a miner
642017-01-24T01:54:30 <gmaxwell> yea, you might not really care about the relay at all.. just plan on extracting the hex and giving it to the antpool doublespending service (I mean free txn priority service)
652017-01-24T02:00:40 <Lightsword> sipa, I think there are enough nodes with inconsistant relay policy that you have a good chance of propagation even if your own mempool doesnât accept the transaction, for example nodes with much more strict mempool limiting may accept it
662017-01-24T02:00:54 <sipa> i wonder if that's a temporary thing
672017-01-24T02:02:09 <Lightsword> well extreme mempool limiting is usually due to resource limitations(reducing ram usage)
682017-01-24T02:04:37 <Lightsword> I think in this case the privacy risks are far less of a risk than users messing up the feebump by trying to do it manually and using the wrong utxoâs
692017-01-24T02:04:40 *** isis has quit IRC
702017-01-24T02:08:58 <gmaxwell> well because bumpfee can only diminish change, it's already pretty limited.
712017-01-24T02:09:53 *** AaronvanW has quit IRC
722017-01-24T02:10:33 *** AaronvanW has joined #bitcoin-core-dev
732017-01-24T02:10:45 *** AaronvanW has joined #bitcoin-core-dev
742017-01-24T02:14:41 *** AaronvanW has quit IRC
752017-01-24T02:20:31 *** isis has joined #bitcoin-core-dev
762017-01-24T02:42:21 *** jtimon has quit IRC
772017-01-24T02:53:53 *** dermoth_ has joined #bitcoin-core-dev
782017-01-24T02:54:21 *** dermoth has quit IRC
792017-01-24T02:54:23 *** dermoth_ is now known as dermoth
802017-01-24T02:54:32 *** Kexkey has quit IRC
812017-01-24T03:00:20 *** waxwing has quit IRC
822017-01-24T03:10:53 *** AaronvanW has joined #bitcoin-core-dev
832017-01-24T03:13:44 *** waxwing has joined #bitcoin-core-dev
842017-01-24T03:16:09 *** AaronvanW has quit IRC
852017-01-24T04:05:37 <bitcoin-git> [bitcoin] luke-jr opened pull request #9621: Define, check, and use MIN_TRANSACTION_SIZE as a const (master...cleanup_mintxsize) https://github.com/bitcoin/bitcoin/pull/9621
862017-01-24T04:05:46 *** chris2000 has joined #bitcoin-core-dev
872017-01-24T04:08:46 *** chris200_ has quit IRC
882017-01-24T04:18:25 *** frabrunelle has joined #bitcoin-core-dev
892017-01-24T05:00:11 *** dermoth has quit IRC
902017-01-24T05:00:15 *** waxwing has quit IRC
912017-01-24T05:01:03 *** dermoth has joined #bitcoin-core-dev
922017-01-24T05:12:26 *** chjj has quit IRC
932017-01-24T05:13:29 *** waxwing has joined #bitcoin-core-dev
942017-01-24T05:16:51 *** AaronvanW has joined #bitcoin-core-dev
952017-01-24T05:16:51 *** AaronvanW has joined #bitcoin-core-dev
962017-01-24T05:21:29 *** AaronvanW has quit IRC
972017-01-24T05:39:19 *** chjj has joined #bitcoin-core-dev
982017-01-24T05:41:26 <bitcoin-git> [bitcoin] kallewoof opened pull request #9622: [rpc] Bug-fix: listsinceblock should include lost transactions when parameter is a reorg'd block (master...listsinceblock-include-lost-txs) https://github.com/bitcoin/bitcoin/pull/9622
992017-01-24T06:17:53 *** AaronvanW has joined #bitcoin-core-dev
1002017-01-24T06:22:20 *** AaronvanW has quit IRC
1012017-01-24T06:27:33 *** kadoban has quit IRC
1022017-01-24T06:37:13 *** waxwing__ has joined #bitcoin-core-dev
1032017-01-24T06:37:29 *** waxwing has quit IRC
1042017-01-24T06:37:37 *** waxwing__ is now known as waxwing
1052017-01-24T06:57:19 *** Ylbam has joined #bitcoin-core-dev
1062017-01-24T06:59:04 *** Lauda has quit IRC
1072017-01-24T07:00:22 *** Lauda has joined #bitcoin-core-dev
1082017-01-24T07:01:40 <gmaxwell> sipa: please close 9616
1092017-01-24T07:03:58 <gmaxwell> "you promised it would only be a three-line change and you delivered :)" best pull request review comment ever.
1102017-01-24T07:17:36 <sipa> ?
1112017-01-24T07:18:03 <bitcoin-git> [bitcoin] sipa closed pull request #9616: Interested in Fixing Vulnerabilities. (master...master) https://github.com/bitcoin/bitcoin/pull/9616
1122017-01-24T07:18:38 *** AaronvanW has joined #bitcoin-core-dev
1132017-01-24T07:20:25 <gmaxwell> sipa: thanks
1142017-01-24T07:20:38 *** Lauda has quit IRC
1152017-01-24T07:22:02 *** Lauda has joined #bitcoin-core-dev
1162017-01-24T07:23:10 *** AaronvanW has quit IRC
1172017-01-24T08:09:44 *** BashCo has quit IRC
1182017-01-24T08:10:26 *** BashCo has joined #bitcoin-core-dev
1192017-01-24T08:11:38 *** dgenr8 has quit IRC
1202017-01-24T08:15:05 *** BashCo has quit IRC
1212017-01-24T08:16:20 *** dgenr8 has joined #bitcoin-core-dev
1222017-01-24T08:19:29 *** AaronvanW has joined #bitcoin-core-dev
1232017-01-24T08:24:06 *** AaronvanW has quit IRC
1242017-01-24T08:24:28 *** wvr has joined #bitcoin-core-dev
1252017-01-24T08:25:09 <bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/71148b8947fe...50864529b6e7
1262017-01-24T08:25:09 <bitcoin-git> bitcoin/master fa4d478 MarcoFalke: qt: Use nPowTargetSpacing constant
1272017-01-24T08:25:10 <bitcoin-git> bitcoin/master 5086452 Jonas Schnelli: Merge #9588: qt: Use nPowTargetSpacing constant...
1282017-01-24T08:25:22 <bitcoin-git> [bitcoin] jonasschnelli closed pull request #9588: qt: Use nPowTargetSpacing constant (master...Mf1701-qtParams) https://github.com/bitcoin/bitcoin/pull/9588
1292017-01-24T08:30:06 *** BashCo has joined #bitcoin-core-dev
1302017-01-24T08:36:27 *** Guyver2 has joined #bitcoin-core-dev
1312017-01-24T08:55:20 *** echonaut1 has joined #bitcoin-core-dev
1322017-01-24T08:55:24 *** echonaut has quit IRC
1332017-01-24T09:08:32 <bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/50864529b6e7...4a1dc35ca532
1342017-01-24T09:08:33 <bitcoin-git> bitcoin/master ff25c32 Wladimir J. van der Laan: mempool: add notification for added/removed entries...
1352017-01-24T09:08:33 <bitcoin-git> bitcoin/master 4afbde6 Alex Morcos: Introduce MemPoolConflictRemovalTracker...
1362017-01-24T09:08:34 <bitcoin-git> bitcoin/master 094e4b3 Alex Morcos: Better document usage of SyncTransaction
1372017-01-24T09:08:40 <bitcoin-git> [bitcoin] laanwj closed pull request #9371: Notify on removal (master...notifyOnRemoval) https://github.com/bitcoin/bitcoin/pull/9371
1382017-01-24T09:14:47 *** jannes has joined #bitcoin-core-dev
1392017-01-24T09:20:12 *** AaronvanW has joined #bitcoin-core-dev
1402017-01-24T09:24:29 *** AaronvanW has quit IRC
1412017-01-24T09:47:32 *** Guyver2 has quit IRC
1422017-01-24T10:04:58 <gmaxwell> "systemd local root exploit" ... gentoo user not affected.
1432017-01-24T10:14:55 *** MarcoFalke has joined #bitcoin-core-dev
1442017-01-24T10:16:10 *** Alopex has quit IRC
1452017-01-24T10:18:15 *** MarcoFalke has quit IRC
1462017-01-24T10:19:39 *** AaronvanW has joined #bitcoin-core-dev
1472017-01-24T10:35:21 *** paveljanik has joined #bitcoin-core-dev
1482017-01-24T10:35:21 *** paveljanik has joined #bitcoin-core-dev
1492017-01-24T10:56:19 *** laurentmt has joined #bitcoin-core-dev
1502017-01-24T10:57:32 *** laurentmt has quit IRC
1512017-01-24T11:14:13 <morcos> wumpus: thanks for merging 9371! i think we're starting to get 0.14 in our sights
1522017-01-24T11:14:44 <wumpus> indeed! it's starting to look quit good
1532017-01-24T11:14:47 <morcos> gmaxwell: which importmulti fixes did you want to get in for 0.14, besides the watch only timestamp PR that is already tagged?
1542017-01-24T11:14:49 <wumpus> quitE
1552017-01-24T11:50:00 *** JackH has quit IRC
1562017-01-24T12:17:19 *** waxwing has quit IRC
1572017-01-24T12:21:36 <bitcoin-git> [bitcoin] laanwj closed pull request #8549: zmq: mempool notifications (master...zmq_mempool) https://github.com/bitcoin/bitcoin/pull/8549
1582017-01-24T12:27:35 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4a1dc35ca532...1ac878ace623
1592017-01-24T12:27:36 <bitcoin-git> bitcoin/master be31a2b Lauda: [Trivial] Update license year range to 2017...
1602017-01-24T12:27:36 <bitcoin-git> bitcoin/master 1ac878a Wladimir J. van der Laan: Merge #9617: [Trivial] Update license year range to 2017...
1612017-01-24T12:27:54 <bitcoin-git> [bitcoin] laanwj closed pull request #9617: [Trivial] Update license year range to 2017 (master...master) https://github.com/bitcoin/bitcoin/pull/9617
1622017-01-24T12:33:34 *** rafalcpp has joined #bitcoin-core-dev
1632017-01-24T12:38:16 *** waxwing has joined #bitcoin-core-dev
1642017-01-24T13:10:46 <bitcoin-git> [bitcoin] jonasschnelli closed pull request #9284: Suppress some annoying deprecation warnings (OSX) (master...2016/12/osx_warnings) https://github.com/bitcoin/bitcoin/pull/9284
1652017-01-24T13:11:05 <bitcoin-git> [bitcoin] jonasschnelli closed pull request #9076: [WIP][Experimental] Add Hybrid full block SPV mode (master...2016/10/spv) https://github.com/bitcoin/bitcoin/pull/9076
1662017-01-24T13:12:38 <bitcoin-git> [bitcoin] jonasschnelli closed pull request #8745: [PoC] Add wallet inspection and modification tool "bitcoin-wallet-tool" (master...2016/09/wallet-tool) https://github.com/bitcoin/bitcoin/pull/8745
1672017-01-24T13:13:37 *** cryptapus has joined #bitcoin-core-dev
1682017-01-24T13:22:45 *** jtimon has joined #bitcoin-core-dev
1692017-01-24T13:24:37 *** BashCo has quit IRC
1702017-01-24T13:26:44 <jonasschnelli> This little refactoring seems readyish: https://github.com/bitcoin/bitcoin/pull/9143
1712017-01-24T13:26:56 <jonasschnelli> Ahm... right. The freeze.
1722017-01-24T13:41:11 <wumpus> yeah I'm not sure whether it makes sense to do now - a pure refactor is not a bugfix but neither is it a feature - depends on the regression risk I suppose
1732017-01-24T13:48:05 <jonasschnelli> Better after we branch of 0.14
1742017-01-24T13:52:15 *** kadoban has joined #bitcoin-core-dev
1752017-01-24T14:00:53 <bitcoin-git> [bitcoin] s-matthew-english opened pull request #9623: fixing typo in README (master...patch-14) https://github.com/bitcoin/bitcoin/pull/9623
1762017-01-24T14:01:35 *** jannes has quit IRC
1772017-01-24T14:11:57 *** jannes has joined #bitcoin-core-dev
1782017-01-24T14:30:08 *** Chris_Stewart_5 has quit IRC
1792017-01-24T14:45:09 *** moli_ has joined #bitcoin-core-dev
1802017-01-24T14:46:32 *** moli has quit IRC
1812017-01-24T14:46:33 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1822017-01-24T14:51:16 *** cryptapus has quit IRC
1832017-01-24T15:21:45 <jonasschnelli> sf boost download issues in travis: https://travis-ci.org/bitcoin/bitcoin/jobs/194846204#L537
1842017-01-24T15:21:51 <jonasschnelli> hope it's temp. only
1852017-01-24T15:22:56 *** cryptapus_afk has quit IRC
1862017-01-24T15:25:28 <BlueMatt> so it looks like the archlinux-arm bitcoin packages are being built using a PKGBUILD different from the one published and building a modified 0.13.2 source tree
1872017-01-24T15:25:34 <BlueMatt> over under on a backdoor?
1882017-01-24T15:37:46 <sipa> ugh
1892017-01-24T15:48:13 <BlueMatt> they're looking into it (the alarm guys)
1902017-01-24T15:48:27 <BlueMatt> (thats ArchLinux-ARM)
1912017-01-24T16:20:23 *** cryptapus_afk has joined #bitcoin-core-dev
1922017-01-24T16:20:23 *** cryptapus_afk has joined #bitcoin-core-dev
1932017-01-24T16:25:24 *** cryptapus_afk has quit IRC
1942017-01-24T16:26:13 *** Sosumi has joined #bitcoin-core-dev
1952017-01-24T16:32:21 *** cryptapus_afk has joined #bitcoin-core-dev
1962017-01-24T16:32:21 *** cryptapus_afk has joined #bitcoin-core-dev
1972017-01-24T16:43:26 <cfields> jonasschnelli: crontab (to fetch sources on fallback server) wasn't running. should be fixed now, so fallback should work if sf.net 404's
1982017-01-24T16:45:36 *** cryptapus has joined #bitcoin-core-dev
1992017-01-24T16:48:30 *** cryptapus has quit IRC
2002017-01-24T16:52:01 *** d9b4bef9 has quit IRC
2012017-01-24T16:52:24 *** cryptapus_afk has quit IRC
2022017-01-24T16:57:22 *** abpa has joined #bitcoin-core-dev
2032017-01-24T17:08:10 <morcos> sipa: got any ideas on #9620?
2042017-01-24T17:08:12 <gribble> https://github.com/bitcoin/bitcoin/issues/9620 | Wallet lost track of funds · Issue #9620 · bitcoin/bitcoin · GitHub
2052017-01-24T17:14:49 <sipa> morcos: no :(
2062017-01-24T17:27:18 <sipa> morcos: "all i do is sendtoaddress" - "the manual CPFP transaction i created"
2072017-01-24T17:32:07 *** dgenr8 has quit IRC
2082017-01-24T17:32:19 *** dgenr8 has joined #bitcoin-core-dev
2092017-01-24T17:32:47 <bitcoin-git> [bitcoin] jnewbery opened pull request #9624: [Trivial] fix logging typo in FlushStateToDisk() (master...TrivialTypo) https://github.com/bitcoin/bitcoin/pull/9624
2102017-01-24T17:35:28 *** jtimon has quit IRC
2112017-01-24T17:44:11 *** jtimon has joined #bitcoin-core-dev
2122017-01-24T17:45:11 *** jtimon has quit IRC
2132017-01-24T17:45:28 <cfields> BlueMatt: holy crap, arch packages are built by hand and uploaded?
2142017-01-24T17:45:42 <BlueMatt> cfields: on regular arch, yes!
2152017-01-24T17:45:51 <BlueMatt> cfields: (as in, holy crap, dont trust arch packages)
2162017-01-24T17:46:04 <cfields> that's terrifying
2172017-01-24T17:46:12 <BlueMatt> cfields: archlinux-arm has a build farm, apparently
2182017-01-24T17:46:23 <BlueMatt> cfields: everything is, when you look closely
2192017-01-24T17:46:25 <cfields> i went looking for a build log, only to come to the depressing realization :(
2202017-01-24T17:47:04 <cfields> BlueMatt: looks like it's possible to me that their builder gets confused by the tag version, and doesn't end up checking out the tag
2212017-01-24T17:47:04 <BlueMatt> cfields: I dont think there is a single linux distro which I would trust almost in any way at all....even the ones with build farms end up accepting sigs from any one of a million people to update the source files :/
2222017-01-24T17:47:32 <BlueMatt> cfields: the binary reports "v0.13.2.0-0d719145b-dirty"
2232017-01-24T17:47:38 <BlueMatt> that commit is v0.13.2
2242017-01-24T17:47:48 <BlueMatt> (though dunno where the ".0" came from - is that normal for git describe?)
2252017-01-24T17:47:58 <cfields> hmm
2262017-01-24T17:48:03 <BlueMatt> the non-arm archlinux binary properly reports "v0.13.2"
2272017-01-24T17:48:09 <BlueMatt> well, I didnt run it, just strings'd it
2282017-01-24T17:48:16 <cfields> yes, i'm looking at the same now
2292017-01-24T17:49:48 <cfields> ok good, well at least it's based on the right version
2302017-01-24T17:50:03 <bitcoin-git> [bitcoin] morcos opened pull request #9625: Increase minimum debug.log size to 9MB after shrink. (master...shrinkless) https://github.com/bitcoin/bitcoin/pull/9625
2312017-01-24T17:50:06 <BlueMatt> "based on" i mean the "-dirty" coul be anything
2322017-01-24T17:50:17 <cfields> right
2332017-01-24T17:50:51 *** pavel_ has joined #bitcoin-core-dev
2342017-01-24T17:50:56 <BlueMatt> I went through what appears to be their build farm tool at https://github.com/archlinuxarm/plugbuild and noted changes it makes to the PKGBUILD file at https://github.com/archlinuxarm/plugbuild/blob/master/client.pl#L344
2352017-01-24T17:51:07 <BlueMatt> but was still unable to reproduce the PKGBUILD hash claimed in the .BUILDINFO file
2362017-01-24T17:53:36 <cfields> where's the .BUILDINFO coming from?
2372017-01-24T17:54:01 <BlueMatt> the .pkg.tar.xz thing that is the package itself has a .BUILDINFO file in it
2382017-01-24T17:54:11 *** paveljanik has quit IRC
2392017-01-24T17:54:15 <cfields> ah, thanks. grabbing
2402017-01-24T17:55:27 <BlueMatt> (note that the pkgbuild_sha256sum in the non-arm archlinux packages also doesnt match, but I cant figure out what modifications might be happening before that hash is calculated)
2412017-01-24T17:55:54 *** pavel_ has quit IRC
2422017-01-24T18:18:49 *** jannes has quit IRC
2432017-01-24T18:28:07 *** paveljanik has joined #bitcoin-core-dev
2442017-01-24T18:28:07 *** paveljanik has joined #bitcoin-core-dev
2452017-01-24T18:28:28 *** cryptapus_afk has joined #bitcoin-core-dev
2462017-01-24T18:28:28 *** cryptapus_afk has joined #bitcoin-core-dev
2472017-01-24T18:42:45 *** windsok has quit IRC
2482017-01-24T18:46:52 *** BashCo has joined #bitcoin-core-dev
2492017-01-24T19:04:57 *** laurentmt has joined #bitcoin-core-dev
2502017-01-24T19:05:24 *** laurentmt has quit IRC
2512017-01-24T19:06:40 *** jnewbery has joined #bitcoin-core-dev
2522017-01-24T19:10:33 <morcos> gmaxwell: that -shrinkdebugfile is only defaulted on if no debug options are present, you don't think 9MB is enough then?
2532017-01-24T19:12:36 *** cryptapus_afk has quit IRC
2542017-01-24T19:13:49 <gmaxwell> morcos: I know-- my though is that I've troubleshoot people on nodes that went out of sync two weeks before, and their log was full of connect/disconnect messages. Maybe you're right that 9MB is enough. I do sort of wish critical errors went into a seperate very low volume log that was never rotated.
2552017-01-24T19:14:23 <morcos> yeah i certainly don't mind doing more, was just tryign to make the patch as unobjectionable as possible
2562017-01-24T19:14:36 <gmaxwell> yea, it's fine.
2572017-01-24T19:33:24 *** windsok has joined #bitcoin-core-dev
2582017-01-24T19:44:02 <jonasschnelli> morcos: The new CWallet::IsChange() function does not work after a zapwallettx, right?
2592017-01-24T19:52:13 <morcos> hmm, jonasschnelli i think your question confused me. Isn't that function old? And I'm not very familiar with zapwallettx, so not really sure what it would do?
2602017-01-24T19:53:04 <jonasschnelli> morcos: I though it's a new one... I'm doing my bumpfee review pretty late. I know.. but I just had the feeling that detecting the change output based on the address book is kinda-bad
2612017-01-24T19:54:29 <jonasschnelli> Though,... is change when it's _not_ in the address book. I guess bumpfee should still work after a zapwallettx
2622017-01-24T19:54:45 <morcos> well as far as i can tell it doesn't really matter... the failure modes are : 1) it can't find change (or finds more than 1) and can't bump the tx or 2) it reduces another output to you instead of change, doesn't seem so bad
2632017-01-24T19:55:54 <jonasschnelli> Yes. Right.
2642017-01-24T19:56:31 <jonasschnelli> Have you guys already started working on the case where bumping requires new input?
2652017-01-24T19:56:41 <jonasschnelli> Like when you use subtractfeefromamount
2662017-01-24T19:56:52 <ryanofsky> have not done work on that
2672017-01-24T19:57:23 <jonasschnelli> ryanofsky: thanks for the info. Maybe its not worth the effort..
2682017-01-24T19:57:29 <gmaxwell> being able to spend bumped outputs is more important in that case... since the bumps will tie up more inputs.
2692017-01-24T19:57:40 <morcos> I don't think that makes sense for combination with subtract fee from amount
2702017-01-24T19:58:15 <morcos> well at least i think we should more narrowly define what we are trying to accomplish wiht subtractfeefromamount anyway..
2712017-01-24T19:58:47 <jonasschnelli> morcos: If you have a single input, assume 25BTC, and you spend the 25BTC with subtract-fee-from-amount you endup with a tx without change.
2722017-01-24T19:58:48 <morcos> it causes a lot of complication in the code when as far as i can tell the main use case is just send all this money over there
2732017-01-24T19:59:12 <jonasschnelli> I think its a fantastic feature (subtract fee from amount).
2742017-01-24T19:59:13 <morcos> yeah so the way to bump that is reduce the output in my opinion
2752017-01-24T19:59:34 <jonasschnelli> From other wallet uses-cases, I know that people are trying to send-out the wallet funds with often leaving some coins behind.
2762017-01-24T19:59:49 <morcos> yes, i agree thats a use case worse supporting
2772017-01-24T20:00:44 <morcos> but we use it in a more general sense... which is annoying... like reducing the outputs even further to give ourselves dust change if we would have had sub-dust change... see #9343
2782017-01-24T20:00:46 <gribble> https://github.com/bitcoin/bitcoin/issues/9343 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
2792017-01-24T20:08:41 *** Guyver2 has joined #bitcoin-core-dev
2802017-01-24T20:09:57 <jonasschnelli> Another wild thought,... we should probably reject self created transactions with absurde high fee during signrawtransaction (additional to ATM over sendrawtx)
2812017-01-24T20:17:17 <bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1ac878ace623...b68f898efa09
2822017-01-24T20:17:17 <bitcoin-git> bitcoin/master ac9a846 John Newbery: [Trivial] fix logging typo in FlushStateToDisk()
2832017-01-24T20:17:18 <bitcoin-git> bitcoin/master b68f898 Jonas Schnelli: Merge #9624: [Trivial] fix logging typo in FlushStateToDisk()...
2842017-01-24T20:17:39 <bitcoin-git> [bitcoin] jonasschnelli closed pull request #9624: [Trivial] fix logging typo in FlushStateToDisk() (master...TrivialTypo) https://github.com/bitcoin/bitcoin/pull/9624
2852017-01-24T20:19:35 <gmaxwell> morcos: there are a bunch of small issues, I need to find the branch and pick them up. It mishandles locked wallets (it should reject trying to import a private key when the wallet is locked), if you ask it to import a key without a birthday it just assumes now and can cause funds loss, it's easy to cause it to rescan everything when you didn't think it would... node out of comission for hours
2862017-01-24T20:19:41 <gmaxwell> ...
2872017-01-24T20:20:13 <morcos> right.. well nudge nudge, 0.14 is in the car with the engine running..
2882017-01-24T20:29:07 *** d9b4bef9 has joined #bitcoin-core-dev
2892017-01-24T20:29:33 <BlueMatt> gmaxwell: please at least file issues for known issues and ask to have them marked 0.14....
2902017-01-24T20:31:04 <gmaxwell> sorry for whining, but I already opened an issue for one of them where I _need_ feedback before doing anything, and only morcos commented a bit. #9491
2912017-01-24T20:31:06 <gribble> https://github.com/bitcoin/bitcoin/issues/9491 | Importmulti api is confusing in a way that could lead to funds loss. · Issue #9491 · bitcoin/bitcoin · GitHub
2922017-01-24T20:31:17 <gmaxwell> this is not convincing me of the utility of opening more issues.
2932017-01-24T20:35:08 <BlueMatt> behind on things, sorry :/
2942017-01-24T20:35:28 <BlueMatt> gmaxwell: opening issues gives us all a view into how close we are to release, and also ensures we dont end up with stuff outstanding until a day before rc
2952017-01-24T20:35:57 <BlueMatt> gmaxwell: there are multiple reasons to open issues
2962017-01-24T20:49:11 <gmaxwell> I don't disagree with anything you are saying there. This doesn't change that if you want people opening issues, you need to respond to the issues they open. Asking if fine too, but it will be ultimately ineffective if people feel that they're wasting their time.
2972017-01-24T20:51:40 <BlueMatt> sorry, somehow I had #9491 marked in my mental list of "oh, that one has an open pr for it to fix it already"
2982017-01-24T20:51:41 <gribble> https://github.com/bitcoin/bitcoin/issues/9491 | Importmulti api is confusing in a way that could lead to funds loss. · Issue #9491 · bitcoin/bitcoin · GitHub
2992017-01-24T20:51:48 <BlueMatt> not sure how it got there, but it did
3002017-01-24T20:52:49 <gmaxwell> s/if fine/is fine/
3012017-01-24T20:56:30 *** Lauda has quit IRC
3022017-01-24T20:56:40 *** Lauda has joined #bitcoin-core-dev
3032017-01-24T20:57:58 *** Sosumi has quit IRC
3042017-01-24T21:05:59 *** chjj has quit IRC
3052017-01-24T21:08:14 *** jl2012 has quit IRC
3062017-01-24T21:11:59 *** chjj has joined #bitcoin-core-dev
3072017-01-24T21:37:31 *** shesek has joined #bitcoin-core-dev
3082017-01-24T21:44:02 *** handlex has joined #bitcoin-core-dev
3092017-01-24T22:08:01 *** cryptapus has joined #bitcoin-core-dev
3102017-01-24T22:08:01 *** cryptapus has joined #bitcoin-core-dev
3112017-01-24T22:10:53 *** cryptapus is now known as cryptapus_afk
3122017-01-24T22:12:39 *** handlex has quit IRC
3132017-01-24T22:16:35 *** bsm117532 has quit IRC
3142017-01-24T22:16:48 *** bsm117532 has joined #bitcoin-core-dev
3152017-01-24T22:19:57 <bitcoin-git> [bitcoin] TheBlueMatt opened pull request #9626: Clean up a few CConnman cs_vNodes/CNode things (master...2017-01-remove-broken-unused-funcs) https://github.com/bitcoin/bitcoin/pull/9626
3162017-01-24T22:33:14 *** handlex has joined #bitcoin-core-dev
3172017-01-24T22:38:14 *** handlex has quit IRC
3182017-01-24T23:21:33 *** Guyver2 has quit IRC
3192017-01-24T23:22:06 *** jnewbery has quit IRC
3202017-01-24T23:27:19 *** bsm117532 has quit IRC
3212017-01-24T23:28:18 <cfields> BlueMatt: thanks for remembering those
3222017-01-24T23:28:49 <BlueMatt> can we mark #9622 as 0.14 since its a pretty big bugfix and isnt too complicated?
3232017-01-24T23:28:51 <gribble> https://github.com/bitcoin/bitcoin/issues/9622 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
3242017-01-24T23:30:29 *** bsm117532 has joined #bitcoin-core-dev
3252017-01-24T23:36:51 <cfields> agree
3262017-01-24T23:39:32 *** douglas has joined #bitcoin-core-dev
3272017-01-24T23:41:12 *** douglas has quit IRC