12016-03-17T00:03:19 *** laurentmt has quit IRC
22016-03-17T00:06:49 *** GreenIsMyPepper has quit IRC
32016-03-17T00:08:47 *** GreenIsMyPepper has joined #bitcoin-core-dev
42016-03-17T00:20:20 *** Cory has quit IRC
52016-03-17T00:21:48 *** belcher has quit IRC
62016-03-17T00:22:53 *** PaulCapestany has quit IRC
72016-03-17T00:23:47 *** PaulCapestany has joined #bitcoin-core-dev
82016-03-17T00:24:09 *** Cory has joined #bitcoin-core-dev
92016-03-17T00:29:47 *** wallet42 has quit IRC
102016-03-17T00:35:12 *** belcher has joined #bitcoin-core-dev
112016-03-17T00:55:51 *** randy-waterhouse has quit IRC
122016-03-17T00:56:13 *** jyap has quit IRC
132016-03-17T00:56:49 *** jyap has joined #bitcoin-core-dev
142016-03-17T00:56:49 *** jyap has joined #bitcoin-core-dev
152016-03-17T01:20:59 *** Ylbam has quit IRC
162016-03-17T01:45:43 *** droark has quit IRC
172016-03-17T01:50:02 *** Alopex has quit IRC
182016-03-17T01:51:07 *** Alopex has joined #bitcoin-core-dev
192016-03-17T01:58:52 *** jgarzik__ has quit IRC
202016-03-17T02:10:09 *** wallet42 has joined #bitcoin-core-dev
212016-03-17T02:15:05 *** Chris_Stewart_5 has joined #bitcoin-core-dev
222016-03-17T02:19:39 *** Chris_Stewart_5 has quit IRC
232016-03-17T02:19:39 *** PaulCapestany has quit IRC
242016-03-17T02:19:40 *** jtimon has quit IRC
252016-03-17T02:19:40 *** slackircbridge has quit IRC
262016-03-17T02:19:41 *** fredrin has quit IRC
272016-03-17T02:19:41 *** amiller has quit IRC
282016-03-17T02:19:41 *** jannes has quit IRC
292016-03-17T02:19:43 *** Arnavion has quit IRC
302016-03-17T02:19:43 *** Guest27862 has quit IRC
312016-03-17T02:19:43 *** CodeShark has quit IRC
322016-03-17T02:19:44 *** NicolasDorier has quit IRC
332016-03-17T02:19:44 *** anttea has quit IRC
342016-03-17T02:25:15 *** Chris_Stewart_5 has joined #bitcoin-core-dev
352016-03-17T02:25:15 *** PaulCapestany has joined #bitcoin-core-dev
362016-03-17T02:25:15 *** jtimon has joined #bitcoin-core-dev
372016-03-17T02:25:15 *** slackircbridge has joined #bitcoin-core-dev
382016-03-17T02:25:15 *** fredrin has joined #bitcoin-core-dev
392016-03-17T02:25:15 *** amiller has joined #bitcoin-core-dev
402016-03-17T02:25:15 *** jannes has joined #bitcoin-core-dev
412016-03-17T02:25:15 *** Arnavion has joined #bitcoin-core-dev
422016-03-17T02:25:15 *** Guest27862 has joined #bitcoin-core-dev
432016-03-17T02:25:15 *** CodeShark has joined #bitcoin-core-dev
442016-03-17T02:25:15 *** NicolasDorier has joined #bitcoin-core-dev
452016-03-17T02:25:15 *** anttea has joined #bitcoin-core-dev
462016-03-17T02:25:18 *** Chris_Stewart_5 has quit IRC
472016-03-17T02:25:43 *** PaulCapestany has quit IRC
482016-03-17T02:26:21 *** PaulCapestany has joined #bitcoin-core-dev
492016-03-17T02:41:17 *** belcher has quit IRC
502016-03-17T02:51:00 *** jl2012 has quit IRC
512016-03-17T03:00:37 *** wumpus has quit IRC
522016-03-17T03:02:50 *** wumpus has joined #bitcoin-core-dev
532016-03-17T03:06:03 *** achow101 has quit IRC
542016-03-17T03:24:39 *** wallet42 has quit IRC
552016-03-17T03:35:31 *** BashCo has joined #bitcoin-core-dev
562016-03-17T03:38:14 *** BashCo_ has quit IRC
572016-03-17T03:55:15 *** mrkent has quit IRC
582016-03-17T03:55:36 *** mrkent has joined #bitcoin-core-dev
592016-03-17T04:00:03 *** mrkent has quit IRC
602016-03-17T04:18:46 *** mol11111 has joined #bitcoin-core-dev
612016-03-17T04:19:54 *** randy-waterhouse has joined #bitcoin-core-dev
622016-03-17T04:21:11 *** moli has quit IRC
632016-03-17T05:28:01 *** wallet42 has joined #bitcoin-core-dev
642016-03-17T05:28:54 *** zooko has joined #bitcoin-core-dev
652016-03-17T05:32:34 *** evoskuil has quit IRC
662016-03-17T05:34:54 *** evoskuil has joined #bitcoin-core-dev
672016-03-17T05:57:28 *** gevs has quit IRC
682016-03-17T05:58:56 *** fengling has quit IRC
692016-03-17T06:00:18 *** xiangfu has quit IRC
702016-03-17T06:00:18 *** dermoth has quit IRC
712016-03-17T06:00:54 *** dermoth has joined #bitcoin-core-dev
722016-03-17T06:01:32 *** xiangfu has joined #bitcoin-core-dev
732016-03-17T06:01:47 *** fengling has joined #bitcoin-core-dev
742016-03-17T06:02:55 *** Thireus has joined #bitcoin-core-dev
752016-03-17T06:09:29 *** gevs has joined #bitcoin-core-dev
762016-03-17T06:23:28 *** wallet42 has quit IRC
772016-03-17T06:31:20 *** wallet42 has joined #bitcoin-core-dev
782016-03-17T06:32:42 *** Giszmo has quit IRC
792016-03-17T06:41:37 *** jtimon has quit IRC
802016-03-17T07:18:01 *** Cheeseo has quit IRC
812016-03-17T07:18:59 *** Cheeseo has joined #bitcoin-core-dev
822016-03-17T07:26:22 *** wallet42 has quit IRC
832016-03-17T07:30:24 *** Thireus has quit IRC
842016-03-17T07:34:17 *** Thireus has joined #bitcoin-core-dev
852016-03-17T07:40:01 *** Alopex has quit IRC
862016-03-17T07:41:07 *** Alopex has joined #bitcoin-core-dev
872016-03-17T07:44:32 *** Don_John has quit IRC
882016-03-17T07:51:08 <wumpus> Luke-Jr: can you take a look at https://github.com/bitcoin/bitcoin/pull/7656 (base58 encoding speed up), seems relevant with your libbase58
892016-03-17T07:54:35 * Luke-Jr looks
902016-03-17T07:55:48 <GitHub87> [bitcoin] jonasschnelli closed pull request #6850: Improve AddToWallet performance when rescanning (master...master) https://github.com/bitcoin/bitcoin/pull/6850
912016-03-17T08:06:04 <go1111111> is anyone working on the blockchain verification flag, as Greg describes at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011853.html ? I have some interest in working on it (slowly, as it'd be my first non-test PR)
922016-03-17T08:09:29 *** Thireus has quit IRC
932016-03-17T08:18:45 *** Ylbam has joined #bitcoin-core-dev
942016-03-17T08:23:51 *** mrkent has joined #bitcoin-core-dev
952016-03-17T08:33:12 *** Thireus has joined #bitcoin-core-dev
962016-03-17T08:37:18 *** larrysalibra has joined #bitcoin-core-dev
972016-03-17T08:42:42 *** d_t has quit IRC
982016-03-17T08:43:17 *** d_t has joined #bitcoin-core-dev
992016-03-17T08:44:01 *** zooko has quit IRC
1002016-03-17T09:00:11 <paveljanik> Qt5.6 will be fun - no *.pc files there, no Qt5Core.pc etc.
1012016-03-17T09:03:14 *** larrysalibra has quit IRC
1022016-03-17T09:07:54 <jonasschnelli> paveljanik: but finally HiDPI support for Linux/Win
1032016-03-17T09:14:04 *** B4ckJ4ck007 has joined #bitcoin-core-dev
1042016-03-17T09:14:18 <paveljanik> I'll try to workaround it somehow
1052016-03-17T09:15:44 *** cjcj has joined #bitcoin-core-dev
1062016-03-17T09:35:17 *** mrkent has quit IRC
1072016-03-17T09:44:31 <paveljanik> jonasschnelli, it will be fun 8) https://bugreports.qt.io/browse/QTBUG-50073
1082016-03-17T09:45:01 <jonasschnelli> Indeed!
1092016-03-17T09:57:14 *** wallet42 has joined #bitcoin-core-dev
1102016-03-17T10:27:55 <GitHub73> [bitcoin] MarcoFalke opened pull request #7702: [qa] Add tests verifychain, lockunspent, getbalance, listsinceblock (master...Mf1603-qaCleanup2) https://github.com/bitcoin/bitcoin/pull/7702
1112016-03-17T10:32:11 *** jl2012 has joined #bitcoin-core-dev
1122016-03-17T10:33:01 *** MarcoFalke has joined #bitcoin-core-dev
1132016-03-17T10:34:18 *** laurentmt has joined #bitcoin-core-dev
1142016-03-17T10:35:45 *** laurentmt has quit IRC
1152016-03-17T10:49:41 *** gevs has quit IRC
1162016-03-17T11:13:54 *** randy-waterhouse has quit IRC
1172016-03-17T11:15:21 *** gevs has joined #bitcoin-core-dev
1182016-03-17T11:40:59 *** AaronvanW has quit IRC
1192016-03-17T11:55:29 *** testnet010 has joined #bitcoin-core-dev
1202016-03-17T11:55:32 <GitHub167> [bitcoin] laanwj opened pull request #7703: tor: Change auth order to only use HASHEDPASSWORD if -torpassword (master...2016_03_auth_order) https://github.com/bitcoin/bitcoin/pull/7703
1212016-03-17T11:56:12 <testnet010> hello all I was hoping someone could help me
1222016-03-17T11:56:27 <testnet010> I am trying to mine bitcoins on testnet solo using cgminer
1232016-03-17T11:57:27 <testnet010> I am getting the following error: Failed to resolve (?wrong URL) testnet.solo.ckpool.org:3333
1242016-03-17T12:08:32 <sipa> ask in #cgminer
1252016-03-17T12:34:18 <GitHub20> [bitcoin] laanwj pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/14d6324a248d...01f42676236b
1262016-03-17T12:34:19 <GitHub20> bitcoin/master 7659438 Suhas Daftuar: CTxMemPool::removeForBlock now uses RemoveStaged
1272016-03-17T12:34:20 <GitHub20> bitcoin/master 5de2baa Suhas Daftuar: Rename CTxMemPool::remove -> removeRecursive...
1282016-03-17T12:34:20 <GitHub20> bitcoin/master 76a7632 Suhas Daftuar: Remove work limit in UpdateForDescendants()...
1292016-03-17T12:34:28 <GitHub26> [bitcoin] laanwj closed pull request #7594: Mempool: Add tracking of ancestor packages (master...ancestor-tracking) https://github.com/bitcoin/bitcoin/pull/7594
1302016-03-17T12:37:39 <GitHub103> [bitcoin] jtimon closed pull request #7665: Contrib: Introduce script to tag compiled binaries for convenience (py) (master...0.12.99-contrib-tag) https://github.com/bitcoin/bitcoin/pull/7665
1312016-03-17T12:38:49 <GitHub60> [bitcoin] laanwj closed pull request #6816: BIP9: versionbits (master...versionbits) https://github.com/bitcoin/bitcoin/pull/6816
1322016-03-17T12:40:12 *** jtimon has joined #bitcoin-core-dev
1332016-03-17T12:57:54 *** wallet42 has quit IRC
1342016-03-17T13:06:32 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1352016-03-17T13:46:57 *** plopi has joined #bitcoin-core-dev
1362016-03-17T13:48:36 <plopi> hi, can I use bitcoind in a nodejs server (for a game) without downloading the entire blockchain? thanks
1372016-03-17T14:05:30 <wumpus> you'll need to download the entire blockchain, you don't have to store it though if you use pruning
1382016-03-17T14:10:43 *** Chris_Stewart_5 has quit IRC
1392016-03-17T14:24:39 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1402016-03-17T14:42:59 <Chris_Stewart_5> Is there any way to play with bitcoin core in an interpreter like environment?
1412016-03-17T14:43:38 <kanzure> if you mean testing, then use regtest mode and bitcoin-cli
1422016-03-17T14:44:57 *** Guyver2 has joined #bitcoin-core-dev
1432016-03-17T14:45:51 <Chris_Stewart_5> No more like seeing how things are serialized, i.e. a python like interpreter. I don't want to spend 5 minutes waiting for bitcoind to compile just to see how certain things are serialized
1442016-03-17T14:46:09 <Chris_Stewart_5> but I'm guessing that is just a limitation of c++
1452016-03-17T14:48:08 <wumpus> python-bitcoinlib is your friend
1462016-03-17T15:03:39 *** drumf has joined #bitcoin-core-dev
1472016-03-17T15:08:43 <morcos> wumpus: sipa: there may be two problems here with the new conflict / abandontransaction code.
1482016-03-17T15:09:32 <morcos> we haven't finished trackign it all down, but our guess is that when your wallet tx is conflicted via parents that were double spent, that there is no way rescans can identify that your wallet tx should now be conflicted
1492016-03-17T15:10:30 <morcos> that is, if the parents weren't wallet txs, and the parents are now gone, b/c they were double spent, the chain is broken and there is no way to trace the double spend down to your wallet tx
1502016-03-17T15:11:11 <instagibbs> Chris_Stewart_5, perhaps not as well-tested, but online: https://blockchainprogramming.azurewebsites.net/checkscript
1512016-03-17T15:11:40 <morcos> separately i believe that abandontransaction doesn't work for not counting new funds you've received, it only works for no longer counting spends.
1522016-03-17T15:12:21 <morcos> i need to look back and see why it was made that way, it sounds vaguely familiar to me that i might have known that
1532016-03-17T15:15:42 <wumpus> I think abandontransaction should work for any transaction that is not confirmed and not in the mempool
1542016-03-17T15:16:05 *** Giszmo has joined #bitcoin-core-dev
1552016-03-17T15:16:32 <wumpus> looks like there's a lot of edge cases otherwise, in the checks to see if it's actually a double spend or conflict
1562016-03-17T15:17:33 <morcos> wumpus: it's possible. the purpose of it was so that you didn't keep tying up your inputs. remember, many people didn't even want it for 0.12. so i think you might be right, but it takes more careful thinking about the issue of what it means to abandon another transaction. for instance you don't know if the guy who sent it to you is getting it mined another way.
1572016-03-17T15:18:35 <morcos> the fundamental problem is we've now got these txs that are severed from any connection to the blockchain by missing parents, so we can't detect them as conflicted. surely the right answer isn't to manually abandon each one
1582016-03-17T15:19:01 <morcos> but honestly, i'm not sure how to fix it. it seems a pretty big problem.
1592016-03-17T15:19:30 <wumpus> "for instance you don't know if the guy who sent it to you is getting it mined another way" right, you can be sure
1602016-03-17T15:19:52 <wumpus> can't*
1612016-03-17T15:20:40 <wumpus> but it may not be realistic to protect against that in the command
1622016-03-17T15:21:27 <wumpus> the user needs to be aware not to use it in such cases
1632016-03-17T15:21:59 <morcos> sdaftuar is suggesting that maybe the right answer is to never count in your balance unconfirmed txs that aren't in your mempool
1642016-03-17T15:22:22 <GitHub142> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/01f42676236b...f034bced269c
1652016-03-17T15:22:23 <GitHub142> bitcoin/master fa48bb3 MarcoFalke: [qt] Remove 0-fee from send dialog
1662016-03-17T15:22:23 <GitHub142> bitcoin/master fae8467 MarcoFalke: [qt] Remove unneeded "fSendFreeTransactions" check
1672016-03-17T15:22:24 <GitHub142> bitcoin/master f034bce Wladimir J. van der Laan: Merge #7686: [qt] Remove 0-fee from send dialog...
1682016-03-17T15:22:24 <sipa> ^ i was about to suggest that
1692016-03-17T15:22:32 <GitHub102> [bitcoin] laanwj closed pull request #7686: [qt] Remove 0-fee from send dialog (master...Mf1603-qt-0-fee) https://github.com/bitcoin/bitcoin/pull/7686
1702016-03-17T15:23:08 <morcos> so for outputs received, it works the same as it did before the change to conflicts. for inputs spent, it works as it does in 0.12. they are still spent unless you abandon them
1712016-03-17T15:23:37 <morcos> that seems relatively reasonable to me
1722016-03-17T15:23:57 <wumpus> I think that makes sense
1732016-03-17T15:26:27 *** Aleph0 has quit IRC
1742016-03-17T15:27:13 <morcos> wumpus: here was the list of unfinished business from abandontransaction
1752016-03-17T15:27:15 *** Aleph0 has joined #bitcoin-core-dev
1762016-03-17T15:27:17 <morcos> Return abandoned status in listtransactions
1772016-03-17T15:27:18 <morcos> Return abandoned status in GUI
1782016-03-17T15:27:18 <morcos> Fix any issues with how abandoned txs should sort
1792016-03-17T15:27:20 <morcos> Add a way to abandon transactions from GUI
1802016-03-17T15:28:06 <morcos> In fixing the conflict detection, should we go ahead and add the status in listtransactions? (how many of these changes do you want to make for a point release)
1812016-03-17T15:28:52 <morcos> Also I was hoping to discuss schedule of the impending soft fork today, are we ok waiting until that to release this change...
1822016-03-17T15:29:58 <morcos> And so I'm not going to make any other changes to the functionality abandontransaction, ie. it shouldnt' do anything other than it already does (no longer marking inputs as spent)
1832016-03-17T15:30:01 <wumpus> well for 0.13 we want all of them, I'd say backport the non-GUI ones to 0.12
1842016-03-17T15:30:21 <morcos> is the sorting a GUI only thing?
1852016-03-17T15:30:29 <morcos> i'm not sure i'm the right guy to make those change
1862016-03-17T15:30:31 <morcos> s
1872016-03-17T15:30:43 <morcos> i mean i can hack around in the GUI if you want...
1882016-03-17T15:31:08 <wumpus> the bare minimum for 0.12.1 is that people such as Cocodude can troubleshoot their issue and get rid of those transactions succesfully
1892016-03-17T15:31:25 <morcos> sipa: are you going to do that?
1902016-03-17T15:31:45 <morcos> i can add the abandoned status to listtransactions
1912016-03-17T15:31:53 <wumpus> and a flag to be able to check whether a transactions was abandoned would be great, to be able to verify abandontransaction did its work
1922016-03-17T15:31:59 <sipa> morcos: i can, but i was hoping to get some work on segwit done
1932016-03-17T15:32:14 <morcos> ha ha... pulling out the trump card?
1942016-03-17T15:32:35 <sipa> ?
1952016-03-17T15:32:46 <morcos> i can't argue against that
1962016-03-17T15:33:10 <sipa> ah, i forgot that trump means something else than a politiciam
1972016-03-17T15:33:22 <sdaftuar> hah
1982016-03-17T15:33:46 *** Guyver2_ has joined #bitcoin-core-dev
1992016-03-17T15:33:49 <morcos> ok i'll make the changes to not count as received money if its 0 confirms and not in mempool, and i'll add the abandon status to listtransactions
2002016-03-17T15:33:59 <sipa> great
2012016-03-17T15:35:08 <morcos> i'll also add this to the rpc test, that was a tricky one
2022016-03-17T15:35:26 *** xabbix__ has quit IRC
2032016-03-17T15:36:37 *** xabbix__ has joined #bitcoin-core-dev
2042016-03-17T15:37:43 *** Guyver2 has quit IRC
2052016-03-17T15:37:52 *** Guyver2_ is now known as Guyver2
2062016-03-17T15:49:18 <jonasschnelli> morcos: I can add the abandon function in the GUI
2072016-03-17T15:49:49 <jonasschnelli> A right-click-context menu to abandon should be relatively trivial I guess.
2082016-03-17T15:50:04 <jonasschnelli> The RBF stuff is way more complex. :)
2092016-03-17T15:50:21 <wumpus> awesome
2102016-03-17T15:50:45 <wumpus> I think we should open an issue to track the remaining abandontransaction work
2112016-03-17T15:50:55 <wumpus> I'll open it
2122016-03-17T15:51:04 <jonasschnelli> wumpus: okay. Thanks.
2132016-03-17T15:51:17 *** BitcoinErrorLog has joined #bitcoin-core-dev
2142016-03-17T15:51:22 <jonasschnelli> What else is left next to the GUI and the today identified bug?
2152016-03-17T15:52:00 <BitcoinErrorLog> what's up with this coinbase? http://blockr.io/block/info/403061
2162016-03-17T15:54:52 <wumpus> jonasschnelli: just copied the list from #7312 and added #7690 https://github.com/bitcoin/bitcoin/issues/7704
2172016-03-17T15:55:16 <jonasschnelli> wumpus: perfect!
2182016-03-17T15:55:57 <wumpus> BitcoinErrorLog: what's wrong with it?
2192016-03-17T15:55:58 <sipa> BitcoinErrorLog: what is weird about it?
2202016-03-17T15:58:14 <BitcoinErrorLog> ton of zeroes in the scriptsig, unusual sequence, i'm not sure, just getting others pointing it out
2212016-03-17T15:58:46 <BitcoinErrorLog> 25.59141121 BTC output
2222016-03-17T15:59:34 <morcos> wumpus: just to be clear, i'm not changing abandontransactoin for the last item in your list.
2232016-03-17T15:59:58 <wumpus> morcos: ok
2242016-03-17T16:00:11 <morcos> i'm changing the calculation of the available balance logic to treat depth==0 and !InMempool() coins as not available
2252016-03-17T16:00:29 <morcos> are teh only two places I need to do that AvailableCoins and GetAvailableCredit ?
2262016-03-17T16:00:33 <sipa> morcos: also for listunspent/coin selection?
2272016-03-17T16:00:55 <morcos> sipa: those use availablecoins right?
2282016-03-17T16:00:57 <sipa> seems so, if you change AvailableCoins
2292016-03-17T16:01:02 <wumpus> ok, makes sense, but in that case that leaves the transaction in the list and unabandon-able?
2302016-03-17T16:01:25 <wumpus> it just won't count for the balance, which is good of course
2312016-03-17T16:02:26 <paveljanik> BitcoinErrorLog, 25+fees.
2322016-03-17T16:02:42 <wumpus> or maybe in IsTrusted?
2332016-03-17T16:02:56 <morcos> wumpus: well for instance if you have a tx that has 1 input from you and 1 output to you
2342016-03-17T16:03:20 <morcos> if it is no longer in your mempool, then the output will automatically stop counting in your unconfirmed balance
2352016-03-17T16:03:26 <wumpus> IIRC in many places, like in the UI, IsTrusted is used for "counts towards balance"
2362016-03-17T16:03:33 <morcos> but you'd have to abandon transaction to get it to stop tying up the input
2372016-03-17T16:04:01 <morcos> wumpus: i don't think thats correct. IsTrusted is for the spendable balance.
2382016-03-17T16:04:04 <jonasschnelli> Should we graphical "mark" abandoned transaction in the GUI? Orange icon or so?
2392016-03-17T16:04:15 <wumpus> oh,right
2402016-03-17T16:04:40 <wumpus> yes I'm confused, istrusted is about spendable, this isn't even spendable balance
2412016-03-17T16:04:55 <wumpus> jonasschnelli: SGTM
2422016-03-17T16:05:00 <BitcoinErrorLog> paveljanik: so nothing weird about the rest? that's what i get for reading anything kristov atlas says...
2432016-03-17T16:07:17 <GitHub199> [bitcoin] MarcoFalke opened pull request #7705: [amount] Add tests and make GetFee() monotonic (master...Mf1603-amountFix) https://github.com/bitcoin/bitcoin/pull/7705
2442016-03-17T16:07:25 <paveljanik> BitcoinErrorLog, do you have anything specific?
2452016-03-17T16:08:41 <BitcoinErrorLog> no, sry
2462016-03-17T16:08:53 <MarcoFalke> So is travis declared dead today?
2472016-03-17T16:10:08 <BitcoinErrorLog> paveljanik: atlas was raising an alarm about it, but has since deleted the tweet, i had shared the link with others who thought maybe something was weird, but think maybe just feedback loop of derp
2482016-03-17T16:10:27 <wumpus> MarcoFalke: is it stuck?
2492016-03-17T16:10:31 <MarcoFalke> Oh, travis is just missing some commit
2502016-03-17T16:10:39 <MarcoFalke> need to try twice
2512016-03-17T16:10:48 <MarcoFalke> and force push
2522016-03-17T16:11:17 <morcos> hmm, unfortunately the balance stuff is already broken in other ways
2532016-03-17T16:11:35 *** BitcoinErrorLog has quit IRC
2542016-03-17T16:11:48 <morcos> well, maybe not , i guess it depends on what you expect to happen with non-Final txs
2552016-03-17T16:13:00 <wumpus> sent non-final transactions should probably deduct from the balance, but received ones shouldn't count until they're final?
2562016-03-17T16:13:21 <wumpus> I think that's what I'd expect
2572016-03-17T16:13:30 *** Thireus has quit IRC
2582016-03-17T16:13:39 *** BashCo_ has joined #bitcoin-core-dev
2592016-03-17T16:13:55 <paveljanik> hmm, its coinbare is shown as opt-in RBF at blocktrail 8)
2602016-03-17T16:14:19 <morcos> wumpus: ugh its broken. i think the intention is for received non-final things to count in your unconfirmed balance
2612016-03-17T16:14:19 <sipa> paveljanik: haha
2622016-03-17T16:14:24 <morcos> ok that makes sense
2632016-03-17T16:14:28 <paveljanik> https://www.blocktrail.com/BTC/tx/f27c9c5d13b62674e367a52f931da9bfa3dc747ea7e51fecdf89f33debc11d89
2642016-03-17T16:14:40 <morcos> but if its non-final, it counts in your balance REGARDLESS of whether its conflicted or not
2652016-03-17T16:15:40 <morcos> i think i have to fix that too, so i'll just try to clean it up, but it'll take several of us thinking about whether it is now doing the right thing.
2662016-03-17T16:16:21 <wumpus> one issue at a time morcos :)
2672016-03-17T16:16:30 *** BashCo has quit IRC
2682016-03-17T16:16:52 <morcos> wumpus: well but how can i fix it if its broken in a different way on the same line
2692016-03-17T16:17:12 <morcos> i mean i agree its going to be less trivial to review, but that line is just garbage as written and its the line i need to change.
2702016-03-17T16:17:28 <morcos> in GetUnconfirmedBalance
2712016-03-17T16:17:47 <wumpus> right, agreed, a lot of that balance code is a mess
2722016-03-17T16:18:07 <wumpus> paveljanik: hah
2732016-03-17T16:18:24 <morcos> anywya, got to run to meeting, will do a bit later
2742016-03-17T16:18:33 <wumpus> later
2752016-03-17T16:32:32 *** Guyver2 has quit IRC
2762016-03-17T16:36:27 *** Guyver2 has joined #bitcoin-core-dev
2772016-03-17T16:37:39 *** B4ckJ4ck007 has quit IRC
2782016-03-17T16:38:53 <jonasschnelli> morcos: what's the easiest way of creating a wtx that is not confirmed and not in the mempool (to allow abandoning)?
2792016-03-17T16:39:41 <jonasschnelli> a flush mempool command would be nice for regtest
2802016-03-17T16:40:52 *** mol11111 is now known as moli
2812016-03-17T16:42:08 <jonasschnelli> -walletbroadcast=0 might be useful for a such test-case
2822016-03-17T16:42:58 <sdaftuar> jonasschnelli: i don't know about easiest, but one way that comes to mind for a regtest test would be to create a tx that sends funds to an anyone-can spend output
2832016-03-17T16:43:23 <sdaftuar> then create a transaction that spends that anyone-can-spend output and sends to one of your wallet addresses
2842016-03-17T16:43:27 <sdaftuar> then restart the node
2852016-03-17T16:43:28 <jonasschnelli> sdaftuar: Yes. Should work. -walletbroadcast=0 (create tx, abandon) works also fine.
2862016-03-17T16:43:36 <wumpus> doesn't one of the RPC tests create one?
2872016-03-17T16:43:57 <jonasschnelli> wumpus: Yes. But takes to long for some repetitive GUI debugging. :)
2882016-03-17T16:44:11 <sdaftuar> oh yeah, abandonconflict.py must do this
2892016-03-17T16:44:54 <sdaftuar> ah, in that test the node is just restarted with a higher min relay fee to prevent mempool acceptance
2902016-03-17T16:45:00 <sdaftuar> that is easier!
2912016-03-17T16:47:35 <sipa> does anyone know when the network alert sysyem was last used?
2922016-03-17T16:49:24 <wumpus> sipa: https://en.bitcoin.it/wiki/Alert_system has all alerts ever
2932016-03-17T16:49:47 <wumpus> April 11, 2014
2942016-03-17T16:56:16 <gmaxwell> no, it doesn't have the last one.
2952016-03-17T16:56:18 <gmaxwell> I sent one.
2962016-03-17T16:56:34 <gmaxwell> re the chain split around the strictder deployment.
2972016-03-17T16:56:51 *** BashCo has joined #bitcoin-core-dev
2982016-03-17T16:57:10 <GitHub169> [bitcoin] morcos opened pull request #7706: [WIP] Fix calculation of balances and available coins. (master...fixconflicts2) https://github.com/bitcoin/bitcoin/pull/7706
2992016-03-17T16:57:50 <jonasschnelli> Should we have a "un-abandon" feature in the GUI? Like a toggle?
3002016-03-17T16:59:16 *** BashCo_ has quit IRC
3012016-03-17T17:03:34 *** aknix has joined #bitcoin-core-dev
3022016-03-17T17:07:33 *** MarcoFalke has quit IRC
3032016-03-17T17:16:03 <wumpus> I don't think we should have an un-abandon function
3042016-03-17T17:16:54 <wumpus> gmaxwell: please add it to the wiki then
3052016-03-17T17:34:59 <gmaxwell> can't now.
3062016-03-17T17:36:44 *** hybridsole has quit IRC
3072016-03-17T17:38:23 <wumpus> no problem, but please do add it at some point
3082016-03-17T17:39:12 <wumpus> people always assume that is the full list of alerts, for example I wasn't aware there was another one
3092016-03-17T17:44:40 *** btcdrak has quit IRC
3102016-03-17T17:45:12 *** plopi has quit IRC
3112016-03-17T17:45:14 *** btcdrak has joined #bitcoin-core-dev
3122016-03-17T17:46:20 *** BashCo has quit IRC
3132016-03-17T17:47:20 *** BashCo has joined #bitcoin-core-dev
3142016-03-17T17:51:11 *** Thireus has joined #bitcoin-core-dev
3152016-03-17T17:53:01 *** wallet42 has joined #bitcoin-core-dev
3162016-03-17T17:54:40 *** BashCo has quit IRC
3172016-03-17T17:58:00 *** MrHodl has joined #bitcoin-core-dev
3182016-03-17T17:58:52 *** droark has joined #bitcoin-core-dev
3192016-03-17T17:59:23 *** achow101 has joined #bitcoin-core-dev
3202016-03-17T17:59:33 *** wallet42 has quit IRC
3212016-03-17T18:03:29 *** droark has quit IRC
3222016-03-17T18:04:00 *** droark has joined #bitcoin-core-dev
3232016-03-17T18:04:30 <achow101> Meeting today??
3242016-03-17T18:05:55 *** hsmiths has quit IRC
3252016-03-17T18:07:13 <btcdrak> achow101 in 50 mins
3262016-03-17T18:07:13 *** hsmiths has joined #bitcoin-core-dev
3272016-03-17T18:07:37 <achow101> Oh, daylight savings time. Whoops
3282016-03-17T18:10:50 *** skyraider has joined #bitcoin-core-dev
3292016-03-17T18:13:06 *** mrkent has joined #bitcoin-core-dev
3302016-03-17T18:20:25 <morcos> jonasschnelli: if i did it correctly there isn't much need for an unabandon feature. if it makes it back into your mempool (or into a block) it won't be treated as abandoned any more
3312016-03-17T18:24:37 *** laurentmt has joined #bitcoin-core-dev
3322016-03-17T18:40:49 *** achow101 has quit IRC
3332016-03-17T18:50:07 *** treehug88 has joined #bitcoin-core-dev
3342016-03-17T18:52:21 *** achow101 has joined #bitcoin-core-dev
3352016-03-17T18:53:24 <paveljanik> I probably won't be able to join the beginning of the meeting again. Suggested topic: Qt 5.6 support. Bitcoin Core doesn't compile with it, because Qt 5.6 dropped almost all pkgconfig files, so configure fails.
3362016-03-17T18:53:50 <jonasschnelli> morcos: you said: "if it makes it back into your mempool". How would a abandoned transaction "makes it back into your mempool"?
3372016-03-17T18:54:12 <jonasschnelli> By re-create the identical transaction? By getting it "back" from a different peer?
3382016-03-17T18:54:14 *** mrkent_ has joined #bitcoin-core-dev
3392016-03-17T18:54:20 <morcos> jonasschnelli: most likely it would be relayed to you from somoene else. or you could resubmit it
3402016-03-17T18:54:31 <wumpus> I don't think it makes much sense to discuss qt 5.6 support on the meeting - it's an obvious yes
3412016-03-17T18:54:46 <jonasschnelli> Okay. Got it.
3422016-03-17T18:54:56 <paveljanik> wumpus, sure, but maybe someone volunteers for it ;-)
3432016-03-17T18:55:11 <wumpus> what about you paveljanik? open source is mostly 'scratch your own itch'
3442016-03-17T18:55:13 *** tubro has joined #bitcoin-core-dev
3452016-03-17T18:55:24 <jonasschnelli> paveljanik wumpus: Yes. The guy who did Qt5.5,.. maybe.
3462016-03-17T18:55:42 <paveljanik> I'll try, but maybe someone else does faster than me.
3472016-03-17T18:55:46 <paveljanik> Have to leave now...
3482016-03-17T18:55:49 <wumpus> ok, later
3492016-03-17T18:55:53 <jonasschnelli> cu
3502016-03-17T18:56:24 *** mrkent has quit IRC
3512016-03-17T18:58:03 *** frankenmint has joined #bitcoin-core-dev
3522016-03-17T19:00:26 <morcos> suggested meeting topic: Scheduling the first BIP 9 sort fork for BIPs 68, 112, 113 (have to merge 7575 first, click the button wumpus)
3532016-03-17T19:00:27 <wumpus> meeting time?
3542016-03-17T19:00:32 <btcdrak> yes!
3552016-03-17T19:00:37 <wumpus> #startmeeting
3562016-03-17T19:00:37 <lightningbot> Meeting started Thu Mar 17 19:00:37 2016 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
3572016-03-17T19:00:37 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
3582016-03-17T19:00:47 <sipa> ohai
3592016-03-17T19:01:17 <wumpus> ok, that will be first morcos, anyone else with topic suggestions?
3602016-03-17T19:01:50 *** Core_ has joined #bitcoin-core-dev
3612016-03-17T19:02:12 <wumpus> we had an action item last time to review the backports for r BIP68 and 112
3622016-03-17T19:02:36 <wumpus> #topic c: Scheduling the first BIP 9 sort fork for BIPs 68, 112, 113
3632016-03-17T19:02:44 <morcos> that wasn't the whole topic
3642016-03-17T19:02:57 <sdaftuar> i think merging is an action item, not a topic :)
3652016-03-17T19:03:19 <btcdrak> how happy is everyone with 7575?
3662016-03-17T19:03:25 * sipa happy
3672016-03-17T19:03:28 <sdaftuar> +1
3682016-03-17T19:03:29 <wumpus> well if you want to discuss 7575 that's fine with me too
3692016-03-17T19:03:32 * btcdrak happy
3702016-03-17T19:04:00 <morcos> wumpus: well its the blocker on the schedule
3712016-03-17T19:04:04 <wumpus> #action merge #7575
3722016-03-17T19:04:06 <morcos> i'm happy with it as well
3732016-03-17T19:04:47 <morcos> ok so then we just need to adequately review the backports, and we can discuss release?
3742016-03-17T19:04:57 <morcos> what is the start date? is april 1st too soon?
3752016-03-17T19:05:00 <wumpus> I see it got a lot of new acks last day
3762016-03-17T19:05:24 <sipa> thanks to all of sdaftuar's tests :)
3772016-03-17T19:05:31 <morcos> i had suggested that the backports be put all together in 1 PR, but i'm not sure thats actually what you guys would prefer. although i think thats the safest way to test them.
3782016-03-17T19:05:43 <morcos> (well 1 pr for 0.11 and 1 for 0.12)
3792016-03-17T19:05:52 <jonasschnelli> +1
3802016-03-17T19:05:58 <sipa> the moment miners uograde to a release with 7575 in it, the warning.logic will trigger on old nodes
3812016-03-17T19:06:01 <btcdrak> Assuming 7575 is merged, the softfork deployment code is in #7648. morcos and I have backported the mempool stuff
3822016-03-17T19:06:04 <wumpus> morcos: I think it makes sense - you can always separate out commits
3832016-03-17T19:06:21 <sipa> even if it only has softforks with a start time in the guture
3842016-03-17T19:06:25 <sipa> future
3852016-03-17T19:06:42 <sipa> so we shouldn't put it too far in the future
3862016-03-17T19:06:52 <morcos> btcdrak: so will you create a pull that backports it all together for 0.12 (including 7575) and i'll do for 0.11
3872016-03-17T19:06:55 <btcdrak> wumpus: the mempool backports are all done, they only need verification that the cherry-picks are correct
3882016-03-17T19:07:07 <wumpus> okay, good
3892016-03-17T19:07:08 <btcdrak> morcos: ok
3902016-03-17T19:07:58 <btcdrak> who has reviewed https://github.com/bitcoin/bitcoin/pull/7648?
3912016-03-17T19:08:40 <wumpus> no one yet, I think
3922016-03-17T19:08:42 <btcdrak> this is built on #7575 and has additional RPC tests that exercise the BIP9 softfork process and the BIP enforcements for 68,112 and 113
3932016-03-17T19:08:44 <morcos> i think we should announce the start date and bit number on the -dev list as soon as we've agreed on it, so that Classic and other implementations can implement it as well
3942016-03-17T19:09:22 <jonasschnelli> btcdrak: It probably better reviewable after 7575 is merged
3952016-03-17T19:09:39 <gmaxwell> +1
3962016-03-17T19:09:39 <wumpus> #action review #7648 after #7575 is merged
3972016-03-17T19:09:39 <sdaftuar> the final version of the versionbits BIP should similarly be announced i think?
3982016-03-17T19:09:39 <btcdrak> I'll rebase 7648 after 7575 is merged
3992016-03-17T19:10:03 <jonasschnelli> I think we don't need to announce the merge,.. but the release/deployment.
4002016-03-17T19:10:07 <morcos> back in 3 mins
4012016-03-17T19:11:28 <wumpus> yes the start date and bit number certainly needs to be announced
4022016-03-17T19:11:48 <btcdrak> wumpus: and we need to plan the release date to be able to set the start date.
4032016-03-17T19:12:35 <btcdrak> wumpus: morcos and I will have the backport PRs ready to go for 0.12 and 0.11. We've done most of the work already.
4042016-03-17T19:12:49 <wumpus> great!
4052016-03-17T19:13:08 <wumpus> release date is not entirely predictable, we do want a RC cycle
4062016-03-17T19:13:16 <btcdrak> really, the only holdup is review of #7648. Once that's merged final, the backports are as good as done. They'd only need to be verified for correctness.
4072016-03-17T19:13:24 <sipa> maybe set the date to may 1st?
4082016-03-17T19:13:27 <morcos> I'd suggest moving the start date to April 15th
4092016-03-17T19:13:28 <morcos> oh
4102016-03-17T19:13:29 <morcos> ok
4112016-03-17T19:13:38 <wumpus> may 1st sounds good to me
4122016-03-17T19:14:12 <btcdrak> is that the start date for BIP9?
4132016-03-17T19:14:17 <wumpus> better to leave some time for issues, which will always arise
4142016-03-17T19:14:33 <morcos> so BIP 9 itself is up to date in the BIP repo, I guess that's what matters most for other implementations, not our code readiness
4152016-03-17T19:14:46 <sdaftuar> others may not be aware of that though
4162016-03-17T19:14:57 <sdaftuar> as it's been in flux until recently
4172016-03-17T19:15:24 <morcos> I'm happy to send the follow up to my original email with these announcements. Perhaps we should update BIP's 68,112,113 with the soft fork info
4182016-03-17T19:15:34 <sipa> we want to announce out intention to go ahead with a deployment based on bip9, for 68/112/113, with a given start date
4192016-03-17T19:15:34 <btcdrak> morcos: BIP9 text is uptodate with the implementation
4202016-03-17T19:15:52 <sdaftuar> good point about updating BIP68/112/113
4212016-03-17T19:16:02 <wumpus> yes
4222016-03-17T19:16:03 <btcdrak> OK I'll do that
4232016-03-17T19:16:25 <btcdrak> so is the BIP9 start date May 1st?
4242016-03-17T19:16:47 <morcos> btcdrak: that language is confusing. the date for the first BIP9 soft fork is May 1st
4252016-03-17T19:16:49 <sdaftuar> May 1st is the startdate for the CSV deployment
4262016-03-17T19:16:53 <morcos> yep
4272016-03-17T19:16:56 <sdaftuar> (or whatever we're calling it)
4282016-03-17T19:17:20 <sipa> once we have code running anywhere in production with a given start date, that date cannot be postponed anymore
4292016-03-17T19:17:27 <sipa> or there is a fork risk
4302016-03-17T19:17:31 <morcos> CSV deployment makes sense to me, it captures most of it, perhaps it would be helpful to add a comment next to the deployment, which BIPS it implements
4312016-03-17T19:17:37 <sipa> moving the start time back is possible
4322016-03-17T19:17:45 <btcdrak> yeah, it's already called CSV deployment in the code.
4332016-03-17T19:18:39 <wumpus> ok, so aim is may 1st
4342016-03-17T19:18:41 <btcdrak> ok so action point is update BIP68/112/113 deployment section
4352016-03-17T19:18:58 <wumpus> let's make sure to review everything necessary as soon as possible so that it can be merged as soon as possible and we can do the release as soon as possible
4362016-03-17T19:18:58 <morcos> I think it makes sense to include that we Bitcoin Core will have a release well in advance of the start date implementing the fork
4372016-03-17T19:19:11 *** mrkent has joined #bitcoin-core-dev
4382016-03-17T19:19:36 <btcdrak> regarding choosing the bit, I guess bit 0 makes sense.
4392016-03-17T19:19:53 <sdaftuar> just please don't choose bit 28
4402016-03-17T19:20:03 *** mrkent_ has quit IRC
4412016-03-17T19:20:09 <wumpus> or 13 :)
4422016-03-17T19:20:19 <btcdrak> The Chinese like 8
4432016-03-17T19:20:20 <btcdrak> ha
4442016-03-17T19:20:44 <wumpus> but yes it makes sense just to allocate 0
4452016-03-17T19:21:09 <wumpus> easier to keep track if they're simply dealt out in order
4462016-03-17T19:21:22 <morcos> what is the block number classic uses?
4472016-03-17T19:21:38 *** testnet010 has quit IRC
4482016-03-17T19:21:57 <btcdrak> BIP109 uses one of the top 3 ::sigh::
4492016-03-17T19:22:19 <jonasschnelli> https://github.com/bitcoinclassic/bitcoinclassic/blob/develop/src/primitives/block.h#L13
4502016-03-17T19:22:32 <btcdrak> top bit 010, so it's not actually part of the BIP9 spec
4512016-03-17T19:23:23 <morcos> btcdrak: huh, it looks like they use 001 and then use bit 28 to signal their hard fork
4522016-03-17T19:23:37 <btcdrak> yup
4532016-03-17T19:23:41 <sdaftuar> TESTDUMMY!
4542016-03-17T19:23:42 <sdaftuar> er
4552016-03-17T19:23:49 <jonasschnelli> ;-)
4562016-03-17T19:23:51 <sdaftuar> so that works out fine then?
4572016-03-17T19:23:51 <btcdrak> bwahahaha
4582016-03-17T19:23:55 <wumpus> hehehe
4592016-03-17T19:23:55 <btcdrak> yes
4602016-03-17T19:23:58 <morcos> sdaftuar: thats what i'm hoping you'll answer
4612016-03-17T19:24:20 <morcos> it should, i think
4622016-03-17T19:24:24 <sdaftuar> i think so too
4632016-03-17T19:25:09 <btcdrak> TESTDUMMY is a past deployment, in 2008 so no problem.
4642016-03-17T19:25:13 <wumpus> ok, let's try to be sure about that before committing to one
4652016-03-17T19:25:37 <morcos> jonasschnelli: so we'd like to get that listunspent abandon flag in for 0.12.1 too (but not the gui changes)...
4662016-03-17T19:25:42 <btcdrak> wumpus: it's fine. TESTDUMMY timeout is December 31, 2008
4672016-03-17T19:25:48 <jonasschnelli> morcos: opening PR in 30secs.
4682016-03-17T19:25:50 <morcos> topic: anything else needed for 0.12.1 ?
4692016-03-17T19:26:08 <jonasschnelli> What about the GUI warning capabilities for 0.12.1?
4702016-03-17T19:26:15 <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/7579
4712016-03-17T19:26:18 <wumpus> if it's going to be a softfork release, there shouldn't be much else in 0.12.1
4722016-03-17T19:26:28 <btcdrak> yeah let's keep it small
4732016-03-17T19:26:31 <jonasschnelli> I'm not entierly happy with 7579,... but could be a small step.
4742016-03-17T19:26:47 <btcdrak> postpone 7579
4752016-03-17T19:26:57 <wumpus> 2008? well, let's get into our deloreans
4762016-03-17T19:27:11 *** hybridsole has joined #bitcoin-core-dev
4772016-03-17T19:27:11 <jtimon> sorry, late, reading, super happy with bip9
4782016-03-17T19:27:36 <morcos> jonasschnelli: oh, i'm glad you pointed me to that PR, i didn't know about it, and was separately going to rework warnings. we should fix them for rpc and gui at the same time. so yeah not for 0.12.1
4792016-03-17T19:27:57 <jonasschnelli> 7579 aims for a simple change that is BP compatibile.
4802016-03-17T19:28:01 <wumpus> let's leave that to 0.12.2
4812016-03-17T19:28:07 <jonasschnelli> It does not prevent the whole rework.
4822016-03-17T19:28:11 <wumpus> focus on the softfork
4832016-03-17T19:28:16 <jonasschnelli> +1
4842016-03-17T19:28:20 <btcdrak> wumpus: +1
4852016-03-17T19:28:40 <wumpus> anything that is also required will unpredictably affect the release date
4862016-03-17T19:28:42 <jonasschnelli> The internal warning system was always bad. So no hurry. :)
4872016-03-17T19:28:47 <wumpus> yea...
4882016-03-17T19:29:17 <wumpus> jonasschnelli: I do like 7579 btw
4892016-03-17T19:29:34 <morcos> wumpus: right, so lets review 7706 and jonasschnelli's pull that is now 2 mins overdue as well, b/c i think we need those
4902016-03-17T19:31:06 <wumpus> which one?
4912016-03-17T19:31:21 <morcos> (the flag for abandontransaction in listunspent)
4922016-03-17T19:31:29 <btcdrak> we probably need a new #topic, we've strayed off the original topic
4932016-03-17T19:31:41 <morcos> well its all related to getting 0.12.1 released
4942016-03-17T19:31:47 <wumpus> oh that makes sense, probably a few line change with no impoact outside listunspent
4952016-03-17T19:31:56 <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/7707 (not 7706!)
4962016-03-17T19:31:58 <GitHub84> [bitcoin] jonasschnelli opened pull request #7707: [RPC][QT] UI support for abandoned transactions (master...2016/03/abandon_ui) https://github.com/bitcoin/bitcoin/pull/7707
4972016-03-17T19:32:07 <morcos> jonasschnelli: yeah, mine is 7706, we need both
4982016-03-17T19:32:08 <btcdrak> morcos: but the topic was "Scheduling the first BIP 9 sort fork for BIPs 68, 112, 113"
4992016-03-17T19:32:20 <sipa> i think we should get dgenr8's partition detection improvement reviewed for 0.12.1
5002016-03-17T19:32:28 <jonasschnelli> morcos: Ah. Right.
5012016-03-17T19:32:45 <wumpus> ok, now everyone wants their favorite thing in 0.12.1
5022016-03-17T19:32:46 <jonasschnelli> sipa: PR URL?
5032016-03-17T19:32:46 <morcos> sipa: oh, i like that idea. thats the most effective way to fix the poor situation with the warnings
5042016-03-17T19:32:47 <wumpus> I was trying to avoid this
5052016-03-17T19:32:52 <wumpus> and focus on the softfork
5062016-03-17T19:33:11 <morcos> wumpus: well lets see if the list we come up wiht in the next 5 mins is reasonable
5072016-03-17T19:33:21 <morcos> we don't have to keep adding stuff for the next week
5082016-03-17T19:33:58 <btcdrak> improving the partition warnings would be a great help, because it's currently a _disaster_
5092016-03-17T19:34:00 <jonasschnelli> dgenr8 partition check PR: https://github.com/bitcoin/bitcoin/pull/7568/files
5102016-03-17T19:34:14 <wumpus> minimum risk would be to release 0.12.0 + only softfork backports
5112016-03-17T19:34:48 <wumpus> but I agree if there are critical bugfixes they should be in too
5122016-03-17T19:34:57 <jonasschnelli> I agree. 0.13 Release is 2016-07-01
5132016-03-17T19:35:04 <wumpus> yes
5142016-03-17T19:35:06 <morcos> wumpus: i think the conflict detection issue is potentially large. i'm kind of surprised we haven't seen more complaints about it. i guess people might not rely on unconfirmed balance too much
5152016-03-17T19:35:06 <jonasschnelli> (so not so far away)
5162016-03-17T19:35:08 <sipa> if we don't fix the partition warnings, we should disable them. maintaining the system longer in the current state will just make people ignore them
5172016-03-17T19:35:21 <btcdrak> sipa: +1
5182016-03-17T19:35:33 <wumpus> I agree sipa and morcos
5192016-03-17T19:35:37 <morcos> sipa: have you reviewed the partition PR
5202016-03-17T19:35:38 <wumpus> so let's fix those
5212016-03-17T19:35:39 <wumpus> no more
5222016-03-17T19:36:47 <wumpus> but the softfork is still priority #1
5232016-03-17T19:37:16 *** Core_ has quit IRC
5242016-03-17T19:37:46 <sipa> ok
5252016-03-17T19:38:28 <wumpus> #action for 0.12.1, apart from softfork: fix partition warnings (review #7568), conflict detection issue (#7706)
5262016-03-17T19:39:06 <sipa> morcos: only the concept; i'll review the code too
5272016-03-17T19:39:45 <wumpus> jonasschnelli: we probably want a RPC-only #7707 for 0.12.1
5282016-03-17T19:40:01 <morcos> yep, its one line of code. : )
5292016-03-17T19:40:06 <wumpus> heh
5302016-03-17T19:40:09 <jonasschnelli> wumpus: Agree. You could cherry pick or tell me if i should open a RPC-only PR against 0.12
5312016-03-17T19:40:37 <wumpus> jonasschnelli: oh it's one line, I'll manage :)
5322016-03-17T19:40:46 <jonasschnelli> +1
5332016-03-17T19:41:10 <jonasschnelli> Is a independent commit: 42e945d79fd54ab11ad48978910b42d10c1c7cf8
5342016-03-17T19:41:24 <morcos> i marked 7706 as WIP, but i just want to flesh out the tests. but wouldn't mind somoene else to think about whether its doing the right thing
5352016-03-17T19:41:25 <wumpus> #action for 0.12.1, #7707 (: 42e945d79fd54ab11ad48978910b42d10c1c7cf8 only)
5362016-03-17T19:41:55 <jtimon> wumpus: ACK on just using bits in order
5372016-03-17T19:44:13 <wumpus> that concludes the topic, I think
5382016-03-17T19:44:20 <jonasschnelli> topic prop.: state of SW
5392016-03-17T19:44:35 <wumpus> #topic state of SW
5402016-03-17T19:45:00 * jonasschnelli thinks is rude to look at sipa now...
5412016-03-17T19:45:01 <sipa> i'm working on the post-fork upgrade problem in the current segnet code
5422016-03-17T19:45:19 <jtimon> morcos: the right bit to signal hardforks is the one that helps old nodes declare the first hardfork block invalid. see outdated https://github.com/bitcoin/bitcoin/pull/7566/commits/990dda87b258c1e8d4d35b1fcbae4106303664f0
5432016-03-17T19:45:21 <sipa> next thing after that is rebase on top of versionbitd and do a new segnet
5442016-03-17T19:45:49 <morcos> sipa: new segnet or testnet?
5452016-03-17T19:45:59 <jonasschnelli> samesame?
5462016-03-17T19:46:14 <sipa> new segnet
5472016-03-17T19:46:29 <sipa> though we can independently test on testnet too, of course
5482016-03-17T19:47:20 <jonasschnelli> Are we aiming SW for 0.13.1?
5492016-03-17T19:47:52 <sipa> i'm aiming for SW in 0.11.something, 0.12.something, 0
5502016-03-17T19:47:55 <sipa> 0.13
5512016-03-17T19:48:14 <sipa> it's a softfork, we'll need to backport
5522016-03-17T19:48:20 <morcos> btcdrak: btw, you should make the start date for CSV deployment earlier on testnet. we didn't talk about that. but any reason not to make the start date march 1st?
5532016-03-17T19:48:34 <jonasschnelli> sipa: Agree. Just on the "timeline".
5542016-03-17T19:48:45 <sipa> jonasschnelli: "soon"
5552016-03-17T19:48:57 <jonasschnelli> I love that "soon". :)
5562016-03-17T19:50:10 <jonasschnelli> I'm just asking because some Core Devs did agree a timeline for SW on a a miners/devs/etc. meeting.
5572016-03-17T19:50:19 <jonasschnelli> *agree on a timeline
5582016-03-17T19:50:31 <btcdrak> morcos: ok
5592016-03-17T19:51:04 <sipa> jonasschnelli: i don't care what some people think; a timeline is something you can't promise
5602016-03-17T19:51:12 <sipa> but we can do our best
5612016-03-17T19:51:18 <wumpus> good to watch that timeline but most important is that we don't deploy before it's ready, quality shouldn't suffer under time pressure
5622016-03-17T19:51:19 <jonasschnelli> sipa: fully agree.
5632016-03-17T19:51:36 <btcdrak> sipa: that's fine, so long as we communicate how things are going, that's good enough.
5642016-03-17T19:51:42 <wumpus> worst outcome would be to be scared into delivering something that breaks
5652016-03-17T19:51:48 <jonasschnelli> btcdrak: yes. We just need to communicate.
5662016-03-17T19:51:50 <sipa> yes
5672016-03-17T19:52:21 <jonasschnelli> Lets just say "soon". :)
5682016-03-17T19:52:39 <sipa> i'm glad bip9 seems final
5692016-03-17T19:52:45 <wumpus> me too
5702016-03-17T19:52:59 <jonasschnelli> Yes. Finally.
5712016-03-17T19:53:07 <btcdrak> sipa: party at your house. we'll bring the beers.
5722016-03-17T19:53:13 <wumpus> I think that concludes the meeting?
5732016-03-17T19:53:44 <jonasschnelli> btcdrak finally de-anonymizes at the party.
5742016-03-17T19:53:48 <wumpus> #endmeeting
5752016-03-17T19:53:48 <lightningbot> Meeting ended Thu Mar 17 19:53:48 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
5762016-03-17T19:53:48 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-17-19.00.html
5772016-03-17T19:53:48 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-17-19.00.txt
5782016-03-17T19:53:48 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-17-19.00.log.html
5792016-03-17T19:53:59 <btcdrak> haha
5802016-03-17T19:54:06 <sipa> jonasschnelli: that's why you bring a drink mixer
5812016-03-17T19:54:17 <jonasschnelli> hahaha...
5822016-03-17T19:54:20 <wumpus> hehehe
5832016-03-17T19:54:27 <sipa> ok, afk
5842016-03-17T19:54:30 <jonasschnelli> cu
5852016-03-17T19:54:31 <morcos> now that the meeting is over, can i just ask about these non-final txs again... i just want to avoid a mistake like with paytxfee
5862016-03-17T19:54:36 <wumpus> later
5872016-03-17T19:54:46 <morcos> where we didn't realize how some poeple are using things might get messed up
5882016-03-17T19:55:00 <morcos> it seems hard to me to imagine many people have non-final txs in your wallet
5892016-03-17T19:55:08 <wumpus> safest is always to leave the behavior the same :) but if you change it, just document it properly ,and it's no problem
5902016-03-17T19:55:21 <wumpus> the criticism was that it waswn't mentioned in the release notes
5912016-03-17T19:55:24 <wumpus> not that it changed at all
5922016-03-17T19:55:33 <morcos> ok, but its ok with you if it changes in 0.12.1 then
5932016-03-17T19:55:40 <morcos> i just don't know of any other good way to fix this
5942016-03-17T19:55:46 <wumpus> eh, that certainly shouldn't change between minor releases
5952016-03-17T19:55:51 <wumpus> do that for 0.13
5962016-03-17T19:55:58 <morcos> but you can't fix the problem then
5972016-03-17T19:55:59 <wumpus> for 0.12.1 we want tofix the issue and nothing more
5982016-03-17T19:56:09 <wumpus> without affecting non-final txes
5992016-03-17T19:56:21 <morcos> how can you distinguish between a non-final tx that you want to include in your balance and one that you don't
6002016-03-17T19:56:29 <morcos> if it's conflicted you dont
6012016-03-17T19:56:40 <wumpus> yeah... :/
6022016-03-17T19:56:46 <morcos> but you have no way of knowing whether its actually conflicted or not
6032016-03-17T19:57:01 <wumpus> anyhow I've had a long day, I'm going afk too, can't really concentrate well anymore
6042016-03-17T19:57:10 <btcdrak> morcos: do I need to mention testnet starttime/timeout in the BIPs?
6052016-03-17T19:57:13 <morcos> ok, well i'm going to change it for minor release then
6062016-03-17T19:57:26 <morcos> btcdrak: yes i would
6072016-03-17T19:57:29 <morcos> and bit
6082016-03-17T19:57:40 <morcos> isn't there a section for depolyment
6092016-03-17T19:57:41 <btcdrak> "This BIP is to be deployed by "versionbits" BIP9 using bit 0 with a '''starttime''' of midnight 1st May 2016 UTC (Unix timestamp 1462060800) and '''timeout''' of 1 year at midnight 1st May 2016 UTC (Unix timestamp 1483228800)."
6102016-03-17T19:57:50 <btcdrak> there is
6112016-03-17T19:58:11 <morcos> uh, well your second year shouldn't be 2016
6122016-03-17T19:58:17 <btcdrak> ha
6132016-03-17T19:58:17 <morcos> but also don't you want to make the time out longer?
6142016-03-17T19:58:30 <morcos> i thought we were typically doing 3 year time outs?
6152016-03-17T19:58:31 <btcdrak> a year is fine.
6162016-03-17T19:58:34 <btcdrak> no
6172016-03-17T19:58:39 <btcdrak> the recommendation is 1 year
6182016-03-17T19:58:45 <morcos> in the BIP?
6192016-03-17T19:58:47 <btcdrak> yes
6202016-03-17T19:58:48 <sdaftuar> $ date --date='@1483228800'
6212016-03-17T19:58:48 <sdaftuar> Sat Dec 31 19:00:00 EST 2016
6222016-03-17T19:59:59 *** schmidty has quit IRC
6232016-03-17T20:00:03 <morcos> i'm surprised the recommendation is one year, but ok, that sounds fine to me
6242016-03-17T20:01:09 <btcdrak> sdaftuar: good catch, I made a typo
6252016-03-17T20:02:09 <btcdrak> morcos: so a similar text for testnet then.
6262016-03-17T20:02:35 *** schmidty has joined #bitcoin-core-dev
6272016-03-17T20:03:10 <morcos> yeah, no one else said anything about the mar 1st testnet, but that makes sense to me, not sure what the expiration should be, maybe may 1st ?
6282016-03-17T20:03:17 <morcos> of 2017
6292016-03-17T20:03:43 <morcos> in case there is some delay, seems a bit silly to be screwed on testnet b/c we put the date too early
6302016-03-17T20:08:13 <btcdrak> I'd be more tempted to say the testnet date should be 1st April to give a chance for review of 7648
6312016-03-17T20:16:23 <jtimon> good meeting, more re bip9. Again, I'm super-happy with #7575. And I'm glad that CodeShark rusty and sipa don't seem to hate me after my heterdox review method for bip9, and I'm sorry for being to open too open to offer resistance for potentially/probably/likely stupid things. I feel I've been a pain in the ass with this. I really needed to maintain a parallel branch to whatever was going to be merged for me to review , but next
6322016-03-17T20:16:24 <jtimon> time I can try much harder to filter my nits before I send them. Also, thanks to morcos for re-bringing the "what's wrong with sending early wrong/preemtive warnings to old nodes" issue, looking back that's the only point where I surrender "easily". Sorry again to all 3
6332016-03-17T20:17:24 * btcdrak hands jtimon some BIP9 party beers
6342016-03-17T20:18:13 <morcos> btcdrak: i don't feel strongly, but it doesn't seem like there is any reason to delay on testnet at all. does anyone else have an opinion?
6352016-03-17T20:18:44 <btcdrak> jtimon: https://i.imgur.com/NDBSWOL.jpg
6362016-03-17T20:19:40 <jtimon> morcos: for bip68/bip112/bip113 ? testnet should definitely have an earlier starttime
6372016-03-17T20:19:59 <jtimon> btcdrak: I only have amstel here, but cheers
6382016-03-17T20:20:29 <morcos> jtimon: yeah i think we just need to pick start and end times for test net. i was proposing march 1st for start time and may 1st 2017 (to match mainnet) for end time
6392016-03-17T20:21:20 <btcdrak> morcos: this is what I came up with https://github.com/bitcoin/bips/compare/master...btcdrak:cvsdeploy
6402016-03-17T20:22:27 <jtimon> morcos: ack, but let's make sure we explain why not march 1st 2017 in the code comments, if you hadn't said "(to match mainnet)", I would have asked
6412016-03-17T20:22:34 <morcos> btcdrak: i'd take out the "on mainnet" part of "is to be deployed on mainnet by versionbits"
6422016-03-17T20:23:49 <morcos> btcdrak: i still sligthly vote for march 1st instead of april 1st, but its only a slight preference
6432016-03-17T20:25:21 <jtimon> btw, unrelated, morcos gmaxwell how stupid does https://github.com/jtimon/bitcoin/tree/0.12.99-feerate-test-bug look? would something like that qualify as a "test bug" in libsecp256k1 ?
6442016-03-17T20:25:45 <jtimon> it passed unittests and python ./qa/pull-tester/rpc-tests.py -extended
6452016-03-17T20:26:19 <morcos> jtimon: ha ha
6462016-03-17T20:26:46 <jtimon> wumpus: I'm kind of curious, can I open a PR just to see what travis thinks about it?
6472016-03-17T20:27:01 <jtimon> then close it, of course
6482016-03-17T20:27:14 <morcos> jtimon: i'm not really sure to tell you the truth, i mean even if you made it more egregious, it would probably only fail like an IsDust check or something.
6492016-03-17T20:27:43 <morcos> this is what i was sort of trying to say to wumpus the other day about FeeRates when he didn't want them to be doubles
6502016-03-17T20:27:54 *** laurentmt has quit IRC
6512016-03-17T20:28:00 <morcos> i don't think they matter too much for anything
6522016-03-17T20:28:43 <btcdrak> morcos: done https://github.com/bitcoin/bips/pull/359
6532016-03-17T20:29:24 <morcos> btcdrak: heh, part of me was secretly hoping you would keep april so if anyone complains about the date you would be on the hook at not me.
6542016-03-17T20:29:44 <btcdrak> ha, i realised april fool
6552016-03-17T20:33:41 <btcdrak> sdaftuar: is bit 28 forever in use on regtest then?
6562016-03-17T20:44:11 <jyap> btw, it's soonâ¢
6572016-03-17T20:44:32 <morcos> btcdrak: yeah, but thats the case with any bit used in any soft fork, so we were eventually going to have to figure out what to do about that once we had 29 soft forks
6582016-03-17T20:44:39 <morcos> now we'll ahve to figure it out when we have 28
6592016-03-17T20:54:03 *** frankenmint has quit IRC
6602016-03-17T20:54:32 <btcdrak> morcos: we need to be able to tell regtest what time it is. then we can have multiple deployments on regtest.
6612016-03-17T20:55:13 <morcos> btcdrak: yeah it'll be fixable in some way or another, but in the meantime, you probably want to make it easy to quickly activate any and all soft forks on regtest
6622016-03-17T20:55:19 <morcos> so its best to leave their dates open
6632016-03-17T21:00:17 *** Don_John has joined #bitcoin-core-dev
6642016-03-17T21:11:44 *** tubro has quit IRC
6652016-03-17T21:12:56 *** fengling has quit IRC
6662016-03-17T21:16:36 *** Guyver2 has quit IRC
6672016-03-17T21:17:13 *** fengling has joined #bitcoin-core-dev
6682016-03-17T21:19:03 <jtimon> so, I was just playing around after our conversation yesterday, I wasn't talking about rational numbers for CFeeRate (that would be maaku if he still maintains that position), I just intuitively and irrationally hate CFeeRate for some reason, I'm not sure I can articulate it reasonably yet, but CFeeRate is kind of coupling "presentation precission" with "stored precission" in a way that I deeply dislike, and this sentiment has
6692016-03-17T21:19:03 <jtimon> nothing to do CFeeRate::ToString(). As I was telling, I thought code would probably be faster if the first question after my first explanation was "are you suggesting to make CFeeRate a rational number?". I could have responded with "it is always already a rational number, it just happens that it's a constant" but I really thought that without me actually understanding why was the goal in changing CFeeRate, that wouldn't lead to
6702016-03-17T21:19:03 <jtimon> any productive discussion unless I had some code to make more point more clear. So I rapidly created all the free disruption I could, to see if any of it could be potentially useful to explain my point about CFeeRate being currently ugly/dangerous interface-wise. Then I was negatevely surprised for my code drafts to pass unitests so easily. At some pint I swear that I passed unitests with s/KB/WEBSCALE=TB*1000, but I was creating
6712016-03-17T21:19:03 <jtimon> too much unnecessary disruption to get to this result, so I had to reduce it to something more readable. After many apparently false positives (I knew the rpc tests couldn't possibly let pass some of the things I did), https://github.com/jtimon/bitcoin/tree/0.12.99-feerate-test-bug it's basically what I have, but I still won't push my not-to-be-merged point about CFeeRate having "bad aji" which I'm still not sure I'm right about
6722016-03-17T21:19:03 <jtimon> . seeing KB 3 times in the same line in my disruption commits also showed some potential for simplification, but not very promising. Sorry for the noise, I think I will convince myself there's nothing useful in jtimon/0.12.99-feerate soon.
6732016-03-17T21:22:56 *** fengling has quit IRC
6742016-03-17T21:38:46 *** belcher has joined #bitcoin-core-dev
6752016-03-17T21:39:30 *** cjcj has quit IRC
6762016-03-17T21:48:24 *** treehug88 has quit IRC
6772016-03-17T21:51:59 *** fuc has joined #bitcoin-core-dev
6782016-03-17T21:52:16 *** MrHodl has quit IRC
6792016-03-17T22:10:31 <morcos> wumpus: sipa: gmaxwell: See my latest comments on https://github.com/bitcoin/bitcoin/pull/7706 . It's a bit of a boondoggle.
6802016-03-17T22:11:12 <morcos> Can we discuss tomorrow on IRC? I really think we have to get something done for 0.12.1, so we just need to agree on what it is we want to do.
6812016-03-17T22:11:29 <morcos> I'm unavailable the rest of the evening, but will be online tomorrow.
6822016-03-17T22:48:58 *** randy-waterhouse has joined #bitcoin-core-dev
6832016-03-17T23:05:12 *** laurentmt has joined #bitcoin-core-dev
6842016-03-17T23:10:34 *** skyraider has quit IRC
6852016-03-17T23:12:22 *** davec has quit IRC
6862016-03-17T23:12:38 *** davec has joined #bitcoin-core-dev
6872016-03-17T23:22:15 *** laurentmt has quit IRC
6882016-03-17T23:27:13 *** amiller has quit IRC
6892016-03-17T23:30:12 *** Chris_Stewart_5 has quit IRC
6902016-03-17T23:32:10 *** Guest73422 has joined #bitcoin-core-dev
6912016-03-17T23:41:07 *** Thireus has quit IRC
6922016-03-17T23:45:30 *** Thireus has joined #bitcoin-core-dev
6932016-03-17T23:52:22 *** PRab has quit IRC