12016-12-16T00:04:27 *** wasi has joined #bitcoin-core-dev
22016-12-16T00:07:37 *** Chris_Stewart_5 has quit IRC
32016-12-16T00:10:09 <bitcoin-git> [bitcoin] funbucks opened pull request #9358: Tell github to quit trippin (master...master) https://github.com/bitcoin/bitcoin/pull/9358
42016-12-16T00:18:40 *** PRab_ has quit IRC
52016-12-16T00:18:41 *** PRab has quit IRC
62016-12-16T00:19:25 *** PRab has joined #bitcoin-core-dev
72016-12-16T00:42:12 <gmaxwell> Good news: for a dbcache of size 2000, sipa's "per utxo" cache model is now 22.6% faster than master in a signature validation free chainstate reindex! (benchmarking with a cache size of 300 now, will report back in a few hours)
82016-12-16T00:46:23 *** Chris_Stewart_5 has joined #bitcoin-core-dev
92016-12-16T00:54:03 <bitcoin-git> [bitcoin] theuni closed pull request #9358: Tell github to quit trippin (master...master) https://github.com/bitcoin/bitcoin/pull/9358
102016-12-16T01:23:09 <kallle> According to the bitcoin.it wiki, "CompactSize" is a var int, and CVarInt is an "even more compact integer for the purpose of local storage (which is incompatible with "CompactSize" described here)". But it's described in all documentation there and elsewhere as a "varint". So the varint is the compact size and the CVarInt/VARINT refer to something else. Doesn't that cause confusion?
112016-12-16T01:28:04 <sipa> the CVarInt in serialize.h is a bitcoin core internal thing, only used for the utxo database and undo data
122016-12-16T01:28:14 <sipa> and it doesn't appear anywhere in the p2p protocol
132016-12-16T01:28:34 <sipa> CompactSize is the varint type used in the p2p protocol for vector sizes etc
142016-12-16T01:30:29 <sipa> and yes, it's confusing...
152016-12-16T01:30:38 <sipa> historical reasons :)
162016-12-16T01:33:21 <kallle> Seems like a candidate for renaming but I can see how it would cause issues as people have used the two as they are for years... esp if COMPACTSIZE becomes VARINT.
172016-12-16T01:33:30 *** Chris_Stewart_5 has quit IRC
182016-12-16T01:49:57 *** Chris_Stewart_5 has joined #bitcoin-core-dev
192016-12-16T02:17:22 *** Ylbam has quit IRC
202016-12-16T02:21:28 *** jtimon has quit IRC
212016-12-16T02:23:12 <Chris_Stewart_5> What is the criteria for setting the default dbcache value? Does a BIP have to be proposed to change it?
222016-12-16T02:24:41 <sipa> no
232016-12-16T02:24:53 <sipa> it doesn't affect the network in any way
242016-12-16T02:25:05 <sipa> only your own memory/cpu tradeoff
252016-12-16T02:27:32 <Chris_Stewart_5> What do you think about raising the dbcache defeault value along the lines of your BIP10x proposal of scaling blocksize at the rate of tech growth (.. or something like that)
262016-12-16T02:27:58 <Chris_Stewart_5> I know blocksize/dbcache aren't really related, but I think I was thinking about that as policy for some defaults in bitcoin core.
272016-12-16T02:27:59 <sipa> sure, but it doesn't need any consideration ahead of time
282016-12-16T02:28:11 <sipa> we can just occasionally change defaults to keep up with technology trends
292016-12-16T02:28:48 <sipa> i think bitcoin-qt for example should just detect how much memory you have at startup, and based on that, choose something and let the user customize
302016-12-16T02:29:03 <sipa> it's harder to do that in bitcoind, which we exapct to run on low-power devices too
312016-12-16T02:29:05 <Chris_Stewart_5> I guess it seems like it could break out into a very politicized change, which is why I think the BIP process would be needed -- but I understand what you mean by it doesn't affect consensus
322016-12-16T02:29:35 <gmaxwell> Chris_Stewart_5: that would be like having a BIP for the color of your theme... it's a purely local thing .. it doesn't matter to you what anyone else uses.
332016-12-16T02:29:42 <gmaxwell> It isn't something where "interoperability" is required.
342016-12-16T02:30:20 <sipa> BIP42 suggests that the currency symbol color should be considered
352016-12-16T02:31:10 *** alpalp has quit IRC
362016-12-16T02:33:51 <Chris_Stewart_5> sipa: That is interesting. I kind of like that idea wrt to reading mem and just setting it off of that.
372016-12-16T02:34:23 <sipa> what idea?
382016-12-16T02:34:37 <Chris_Stewart_5> your comment wrt to bitcoin-qt
392016-12-16T02:34:45 <sipa> Chris_Stewart_5: not only does not affect consensus - it doesn't affect anything
402016-12-16T02:35:01 <sipa> BIP32 also does not affect consensus, but it's still very useful to get people to agree on it
412016-12-16T02:35:16 <gmaxwell> Chris_Stewart_5: it would be a wrong assumption to assume the user wants all their memory used by bitcoin. :(
422016-12-16T02:35:48 <Chris_Stewart_5> gmaxwell: absurd! :P
432016-12-16T02:37:05 <gmaxwell> we could certantly reduce it based on the amount of free memory!
442016-12-16T02:37:08 <Chris_Stewart_5> ahh, BIP42, not BIP142. I was thinking there was a proposal for strange chars in segwit addresses
452016-12-16T02:39:52 *** alpalp has joined #bitcoin-core-dev
462016-12-16T02:42:48 <bitcoin-git> [bitcoin] ryanofsky opened pull request #9359: Fix CWalletTx::GetImmatureCredit() returning stale values. (master...pr/immature) https://github.com/bitcoin/bitcoin/pull/9359
472016-12-16T02:42:51 <Chris_Stewart_5> sipa: That made my night. I unequivocally support BIP42 and (while were at it) make PHP great again!
482016-12-16T02:46:37 *** alpalp has quit IRC
492016-12-16T02:47:55 *** alpalp has joined #bitcoin-core-dev
502016-12-16T02:58:26 *** abpa has joined #bitcoin-core-dev
512016-12-16T03:05:53 *** NielsvG has quit IRC
522016-12-16T03:09:18 *** NielsvG has joined #bitcoin-core-dev
532016-12-16T03:09:18 *** NielsvG has joined #bitcoin-core-dev
542016-12-16T03:16:06 *** Alopex has quit IRC
552016-12-16T03:17:12 *** Alopex has joined #bitcoin-core-dev
562016-12-16T03:21:25 *** Kexkey has joined #bitcoin-core-dev
572016-12-16T03:27:11 *** amiller has quit IRC
582016-12-16T03:29:11 *** To7 has quit IRC
592016-12-16T03:35:06 *** Alopex has quit IRC
602016-12-16T03:36:11 *** Alopex has joined #bitcoin-core-dev
612016-12-16T03:48:01 *** Alopex has quit IRC
622016-12-16T03:49:06 *** Alopex has joined #bitcoin-core-dev
632016-12-16T03:49:51 *** Atomicat_ has joined #bitcoin-core-dev
642016-12-16T03:52:42 *** Atomicat has quit IRC
652016-12-16T03:52:43 *** Atomicat_ is now known as Atomicat
662016-12-16T03:53:28 *** Victor_sueca has joined #bitcoin-core-dev
672016-12-16T03:55:40 *** Victorsueca has quit IRC
682016-12-16T03:56:07 *** Kexkey has quit IRC
692016-12-16T04:00:01 *** Alopex has quit IRC
702016-12-16T04:01:06 *** Alopex has joined #bitcoin-core-dev
712016-12-16T04:06:02 *** alpalp has quit IRC
722016-12-16T04:10:04 *** MurhS0xFF has joined #bitcoin-core-dev
732016-12-16T04:19:29 *** Chris_Stewart_5 has quit IRC
742016-12-16T04:20:42 *** Victor_sueca has quit IRC
752016-12-16T04:33:39 *** chris200_ has joined #bitcoin-core-dev
762016-12-16T04:37:13 *** chris2000 has quit IRC
772016-12-16T04:52:58 *** abpa has quit IRC
782016-12-16T05:02:43 *** Giszmo has quit IRC
792016-12-16T05:22:55 *** To7 has joined #bitcoin-core-dev
802016-12-16T05:26:31 *** MurhS0xFF has quit IRC
812016-12-16T06:00:49 *** justan0theruser has joined #bitcoin-core-dev
822016-12-16T06:03:48 *** justanotheruser has quit IRC
832016-12-16T06:20:01 *** Chris_Stewart_5 has joined #bitcoin-core-dev
842016-12-16T06:21:13 *** kadoban has quit IRC
852016-12-16T06:50:10 *** [Author] has quit IRC
862016-12-16T06:50:33 *** [Author] has joined #bitcoin-core-dev
872016-12-16T06:51:04 *** Ylbam has joined #bitcoin-core-dev
882016-12-16T07:19:39 *** wvr has quit IRC
892016-12-16T07:30:51 *** jtimon has joined #bitcoin-core-dev
902016-12-16T07:48:57 *** btcdrak has quit IRC
912016-12-16T08:08:08 <gmaxwell> I currently have a node running 8695, 8808, 9039, 9045, 9125, 9138, and 9199 ... surprisingly all applied without conflict.
922016-12-16T08:08:25 *** btcdrak has joined #bitcoin-core-dev
932016-12-16T08:15:58 *** cannon-c has joined #bitcoin-core-dev
942016-12-16T08:16:31 <NicolasDorier> When I do "fundrawtransaction" followed by a "getnewaddress" I noticed the generated address and the change of funrawtransaction are the same
952016-12-16T08:16:37 <NicolasDorier> is it on purpose ?
962016-12-16T08:17:09 <NicolasDorier> it is like funrawtransaction does not increment the index for generating the next address
972016-12-16T08:17:44 <NicolasDorier> I can do a getnewaddress manually after FundRawTransaction, but first I would like if it is on purpose
982016-12-16T08:19:36 <bitcoin-git> [bitcoin] kallewoof opened pull request #9361: Fix: OSX compile fix: defer to bswap_XX when defined. (master...macosx-qt-build-fix) https://github.com/bitcoin/bitcoin/pull/9361
992016-12-16T08:22:34 <jonasschnelli> NicolasDorier: thats right. Fundrawtransaction does not keep the reserve key.
1002016-12-16T08:23:20 <NicolasDorier> what about adding a new parameter to fundrawtransaction for it to be the case ? I don't want same key used twice by mistake
1012016-12-16T08:23:28 <jonasschnelli> NicolasDorier: what you can and should do is call getrawchangeaddress and use this with fundrawtransaction (you can specify a change address there)
1022016-12-16T08:23:33 <NicolasDorier> ah
1032016-12-16T08:23:35 <NicolasDorier> yes
1042016-12-16T08:23:39 <NicolasDorier> will do that thanks
1052016-12-16T08:23:40 <jonasschnelli> NicolasDorier: yes. We should do that-.
1062016-12-16T08:23:49 <jonasschnelli> It feels llike a serious bug
1072016-12-16T08:23:52 <jonasschnelli> I'm opening an issue
1082016-12-16T08:23:56 <NicolasDorier> thanks
1092016-12-16T08:32:25 *** amiller_ has joined #bitcoin-core-dev
1102016-12-16T08:33:54 *** paveljanik has quit IRC
1112016-12-16T08:34:54 *** Alina-malina has quit IRC
1122016-12-16T08:42:42 *** tunafizz has quit IRC
1132016-12-16T08:43:26 *** tunafizz has joined #bitcoin-core-dev
1142016-12-16T08:44:14 *** Alina-malina has joined #bitcoin-core-dev
1152016-12-16T09:15:49 *** tunafizz has quit IRC
1162016-12-16T09:16:52 *** tunafizz has joined #bitcoin-core-dev
1172016-12-16T09:19:10 <bitcoin-git> [bitcoin] rebroad opened pull request #9363: Don't provide blocktxns for old blocks on a fork. (master...MinChainWorkBlocktxns) https://github.com/bitcoin/bitcoin/pull/9363
1182016-12-16T09:20:50 *** rebroad has joined #bitcoin-core-dev
1192016-12-16T09:32:10 <gmaxwell> rebroad: you know you can run all the tests that travis runs locally?
1202016-12-16T09:36:13 <rebroad> gmaxwell, I assumed it was possible, although I have not yet worked out how to make it do so... I chose the --enable-extended-rpc-tests on the configure, but then couldn't work out what to do following that.
1212016-12-16T09:37:16 <rebroad> and anyway, "make check" is failing on my system... I raised an issue for it.
1222016-12-16T09:38:45 <rebroad> gmaxwell, what prompted you to mention the travis tests?
1232016-12-16T09:40:11 <rebroad> (well, 9 times out of 10 - re "make check")
1242016-12-16T09:40:16 <gmaxwell> rebroad: number of failing test on PR opens from you suggested to me that you weren't aware you could run them locally. (e.g. I follow the link when the bot mentions it in IRC and its failed already).
1252016-12-16T09:41:47 *** LeMiner has joined #bitcoin-core-dev
1262016-12-16T09:41:49 <rebroad> gmaxwell, how do I run them locally please? (I am re-reading the docs now, but have not seen this info as yet)
1272016-12-16T09:42:38 <rebroad> my latest PR seems to have works all except for fundwartransaction.py (https://travis-ci.org/bitcoin/bitcoin/jobs/184479440)
1282016-12-16T09:42:48 <rebroad> and that failed only on 1 of the 6 platforms
1292016-12-16T09:43:18 <rebroad> I'm assuming if I run the tests locally it only tests my own platform
1302016-12-16T09:43:30 <gmaxwell> RE your latest PR, the same behavior exists for blocks it is pointless to be much more restrictive there for getblocktxn than blocks themselves. Also, we don't want to fail to reply to a getblocktxn we might have just offered by sending a compact block and then immediately having a reorg, as that will dos attack our peer. For the code that avoids fingeringprinting with blocks search for "To pre
1312016-12-16T09:43:36 <gmaxwell> vent fingerprinting" in net_processing.cpp.
1322016-12-16T09:46:01 <rebroad> gmaxwell, "same behavior exists for blocks" - same behavior as what? For blocks it checks if it is more than 1 month old - quite different logic than is used for getblocktxns
1332016-12-16T09:46:22 <rebroad> it also checks if it is in the activechain - it doesn't do this for getblocktxns
1342016-12-16T09:46:42 <gmaxwell> rebroad: well you may not be able to test osx locally, though you could test windows if you wanted. You can actually see exactly what travis runs by looking in the file .travis.yml but the relevant command is qa/pull-tester/tpc-tests.py
1352016-12-16T09:46:46 <rebroad> for getblocktxns (from what I can tell) it checks if the height it within a certain height - a height comparison
1362016-12-16T09:47:49 <rebroad> gmaxwell, thanks (re rpc-tests.py) runnnig it now.. somewhat obscure command which I would not have tried unless told
1372016-12-16T09:47:59 <gmaxwell> rebroad: yes but there is no point for the purpose of avoiding fingerprinting in making the test there _more_ restrictive than the one for blocks.
1382016-12-16T09:48:36 <wumpus> rebroad: https://github.com/bitcoin/bitcoin/tree/master/qa on running qa tests locally
1392016-12-16T09:49:12 <wumpus> (this is all linked from the main README.md, you should have no problem finding this documentation if you bothered looking even casually)
1402016-12-16T09:53:04 <wumpus> I'm disappointed that you're constantly submitting issues and even pull request while you apparently don't even know how to run the tests
1412016-12-16T09:53:20 <rebroad> wumpus, I see the section now - yes, it is there - not sure how I missed it last time
1422016-12-16T09:56:18 <rebroad> I don't know when that info was added but it wasn't in there when I last read it - I'm not sure how often I am expected to re-read the README file
1432016-12-16T09:56:37 <jonasschnelli> Also, rebroad: you can setup travis for your own development branch
1442016-12-16T09:56:48 <jonasschnelli> (in case you open PRs to have them run though travis)
1452016-12-16T09:56:59 <wumpus> it was there for a long time, has been updated a few times
1462016-12-16T09:57:05 <rebroad> jonasschnelli, that would be very useful indeed. thanks
1472016-12-16T09:57:18 <jonasschnelli> Just head to http://travis-ci.org
1482016-12-16T09:57:25 <wumpus> and yes you're supposed to keep up to date with the (extrememly minimal) development documentation if you do development
1492016-12-16T09:57:27 <jonasschnelli> and enable you rebroad/bitcoin repo
1502016-12-16T10:01:21 <rebroad> jonasschnelli, it appears I enabled travis for my rebroad/bitcoin more than 9 months ago. I have just revisited it now, but so far am struggling to understand the interface
1512016-12-16T10:01:45 <jonasschnelli> understand travises interface?
1522016-12-16T10:01:59 <wumpus> travis, too, has documentation
1532016-12-16T10:02:30 *** Guyver2 has joined #bitcoin-core-dev
1542016-12-16T10:03:57 <wumpus> it looks like the fundrawtransaction.py test is flaky at the moment
1552016-12-16T10:05:40 <rebroad> running the extended tests locally fundrawtransaction.py passed, but walletbackup.py failed!
1562016-12-16T10:05:43 <jonasschnelli> wumpus: what do you think about https://github.com/bitcoin/bitcoin/issues/9362, it surprises me that nobody has complained about address reuse so far.
1572016-12-16T10:05:52 <rebroad> my one line change doesn't touch things that either of those tests test
1582016-12-16T10:06:43 <wumpus> jonasschnelli: interesting - it's supposed to update the change address when it is actually used
1592016-12-16T10:07:02 <wumpus> jonasschnelli: apparently that logic doesn't work
1602016-12-16T10:07:13 <rebroad> gmaxwell, I am struggling to understand the context of what you are referring to. you mention a "more restrictive test" - but I am not sure which test you mean. The test was previously checking that the height was within 10 blocks from active-tip - it is still that test, but no longer assumes only one chain.
1612016-12-16T10:07:46 <rebroad> gmaxwell, by making that assumption it would respond to requests for any block of that height, whether on the active chain or not
1622016-12-16T10:07:59 <rebroad> (at least, this is my understanding from the code)
1632016-12-16T10:09:24 <rebroad> given the reason for the restriction was to avoid delving into old data and hard-disk read access, then the new check seems a better way, and doesn't apply any additional restrictions over the previous check (other than disallowing other chains where the work would have been much lower - therefore not a problem disabling this from what I can see)
1642016-12-16T10:10:18 <rebroad> if it is intentional to allow access to old blocks on alt chains, but not on the active chain, then I am at a loss why this would be intentional
1652016-12-16T10:11:19 <rebroad> my understanding is that as compact blocks relys on the memory pool, that old blocks on any chain are unnecessary
1662016-12-16T10:11:24 <wumpus> yes this is intentional, it avoids fingerprinting attacks
1672016-12-16T10:11:42 <rebroad> wumpus, it would allow fingerprint attacks, not avoid them
1682016-12-16T10:11:56 <wumpus> peers could fingerprint nodes based on what alt-chains they own - this is avoided now
1692016-12-16T10:12:22 <rebroad> wumpus, which PR are you referring to?
1702016-12-16T10:12:45 <rebroad> wumpus, my PR is a change that avoids fingerprinting. the current master allows it
1712016-12-16T10:12:47 <wumpus> I'm not refering to a PR, but to the reason that access is not allowed to old blocks on alt chains
1722016-12-16T10:13:00 <rebroad> wumpus, my PR stops access to old blocks on alt chains
1732016-12-16T10:13:12 <rebroad> in order to stop fingerprinting
1742016-12-16T10:13:21 *** Alina-malina has quit IRC
1752016-12-16T10:13:21 *** Alina-malina has joined #bitcoin-core-dev
1762016-12-16T10:13:56 <wumpus> anyhow I can't reproduce the fundrawtransaction problem locally either
1772016-12-16T10:14:06 <rebroad> #9363
1782016-12-16T10:14:08 <gribble> https://github.com/bitcoin/bitcoin/issues/9363 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
1792016-12-16T10:14:29 *** jannes has joined #bitcoin-core-dev
1802016-12-16T10:15:58 <rebroad> in order for the fingerprinting to happen, a peer would need to be fed blocks on an alt chain until height within 10 from the current active tip
1812016-12-16T10:16:12 <rebroad> then once that is done, a getblocktxn request would reveal the fingerprint
1822016-12-16T10:16:36 <rebroad> I have not tested this can be done, but from reading the code I believe it could
1832016-12-16T10:17:47 <rebroad> i would like to be able to write a test to show this - i need to become more familiar with the python tests to be able to do this. apologies if I am wrong about my assumption based on reading the code
1842016-12-16T10:18:20 *** murchandamus has quit IRC
1852016-12-16T10:19:09 <rebroad> and to be honest, I am not even sure what the big deal about fingerprinting is, but given it is coded to be protected against, I assumed this vector ought to be closed also
1862016-12-16T10:20:09 <wumpus> I don't understand why you write and submit a patch to do something that you don't even know it's a big deal?
1872016-12-16T10:20:19 <wumpus> why are you working on that at all, then?
1882016-12-16T10:20:39 <rebroad> I don't claim to know anything as Aristotle once said
1892016-12-16T10:20:48 <rebroad> I can go only on assumptions therefore
1902016-12-16T10:20:54 <wumpus> I just don't understand your motivation
1912016-12-16T10:21:18 <rebroad> wumpus, to help. what is your motivation?
1922016-12-16T10:21:22 <wumpus> either you believe fingerprint attacks are a serious attack vector and you try to improve mitigation of them, or you don't just leave the logic alone
1932016-12-16T10:21:30 <wumpus> for which change?
1942016-12-16T10:21:43 <rebroad> wumpus, for the project i mean
1952016-12-16T10:21:57 <wumpus> that's off topic here and certainly not something I want to get into
1962016-12-16T10:22:18 <rebroad> sorry, I answered assuming you were referring to the project, not the PR
1972016-12-16T10:22:46 <wumpus> the only thing relevant here is the motivation to make specific changes to the code, as you need that to convince other people to care about your change
1982016-12-16T10:23:32 <rebroad> wumpus, I assume that given anti-fingerprinting code is already in the code, then a sufficient number of core developers appreciate its importance. I didn't consider that I therefore needed to appreciate it also
1992016-12-16T10:23:48 <rebroad> I mean understand not appreciate
2002016-12-16T10:24:32 <rebroad> anyway, if I was wrong, and it's not important. I will close the PR
2012016-12-16T10:25:01 <rebroad> but it does make me question why it was important for blocks but not blocktxns
2022016-12-16T10:25:10 <wumpus> well your described angle is fine if you care about it: write a test that demonstrates it, then demonstrate that your code fixes that attack
2032016-12-16T10:25:36 <rebroad> wumpus, ok, I will get to work on that.. but before I do.. can anyone explain to me why fingerprinting attacks are bad?
2042016-12-16T10:25:40 <wumpus> if you don't, then don't waste your time
2052016-12-16T10:25:49 <rebroad> wumpus, because if they are not that bad, then it's a lot of effort for something trivial
2062016-12-16T10:26:03 <wumpus> if you don't think they are bad then donj't spend effort on it!
2072016-12-16T10:26:10 <rebroad> wumpus, lol.. ok
2082016-12-16T10:26:16 <wumpus> why do you need to be hand-held through every little thing
2092016-12-16T10:26:39 <rebroad> wumpus, it takes two to hold hands
2102016-12-16T10:27:22 <wumpus> fingerprinting has to do with privacy, especially over tor or other anonymity layers. Theoretically you should not be able to identify a peer connecting to you over tor, but with fingerprinting tricks you can.
2112016-12-16T10:27:32 <rebroad> wumpus, I mean that we both needed to understand each other to work out the way forward
2122016-12-16T10:27:59 <rebroad> wumpus, ah... thanks. i understand now in that context. thank you for explaining
2132016-12-16T10:28:06 <wumpus> if you can distinguish and thus identify peers sending you a transaction you gain information you shouldn't have
2142016-12-16T10:28:21 <wumpus> if you don't care about that, then well, don't
2152016-12-16T10:28:45 <rebroad> wumpus, based on that explanation, I shall work on creating that test you asked for
2162016-12-16T10:28:53 <wumpus> okay thanks
2172016-12-16T10:29:17 *** JackH has joined #bitcoin-core-dev
2182016-12-16T10:31:26 <wumpus> so fundrawtransaction.py test very regularly fails on travis with "Assertion failed: Mempool sync failed"
2192016-12-16T10:31:33 <wumpus> but I can't reproduce this locally
2202016-12-16T10:32:12 <luke-jr> timing maybe?
2212016-12-16T10:32:44 <wumpus> some recent change must have triggered it, it was not the case before
2222016-12-16T10:33:07 <jonasschnelli> wumpus: fundrawtx should not keep the CReserveKey, sendrawtx could, but what solutions do we offer for users broadcastign over different channels...
2232016-12-16T10:33:15 <jonasschnelli> Maybe we should add a call
2242016-12-16T10:33:29 <jonasschnelli> to reserve the used change key of a funded raw tx
2252016-12-16T10:33:43 <jonasschnelli> or to reserve a key by a specific address
2262016-12-16T10:33:51 <jonasschnelli> (and release)
2272016-12-16T10:33:52 <wumpus> jonasschnelli: well for broadcasting over separate channels we can't offer automatic change address functionality
2282016-12-16T10:34:30 <wumpus> jonasschnelli: unless there would be a way to tell the wallet of a transaction without broadcasting it
2292016-12-16T10:34:44 <jonasschnelli> ah,.. right.
2302016-12-16T10:35:12 <wumpus> right now the only way to tell the wallet is sendrawtransaction, which always broadcasts (walletbroadcast=0 setting won't help you there)
2312016-12-16T10:35:24 <jonasschnelli> I guess we should add detecting the change key in sendrawtx and make sure we reserve it from the keypool
2322016-12-16T10:35:52 *** laurentmt has joined #bitcoin-core-dev
2332016-12-16T10:36:11 <wumpus> either that or indeed it should be an explicit step to reserve a change address, which should be returned if not used
2342016-12-16T10:36:37 <wumpus> this was overlooked in the fundrawtransaction design
2352016-12-16T10:38:17 <wumpus> fundrawtransaction doesn't even consistently fail in the same place (!)
2362016-12-16T10:38:30 <wumpus> I mean the test
2372016-12-16T10:38:46 *** murchandamus has joined #bitcoin-core-dev
2382016-12-16T10:39:03 <wumpus> in https://travis-ci.org/bitcoin/bitcoin/jobs/184431201 it's the sync_all on line 534 that fails
2392016-12-16T10:39:14 <wumpus> in https://travis-ci.org/bitcoin/bitcoin/jobs/184473580 it's the one on line 461
2402016-12-16T10:40:21 <wumpus> in https://travis-ci.org/bitcoin/bitcoin/jobs/184333528 it's line 449
2412016-12-16T10:40:40 <wumpus> the only commonality is that the fundrawtransaction.py test fails, and it happens while syncing mempools
2422016-12-16T10:41:16 *** laurentmt has quit IRC
2432016-12-16T10:44:08 *** murchandamus has quit IRC
2442016-12-16T10:46:40 *** rebroad_ has joined #bitcoin-core-dev
2452016-12-16T10:50:13 *** rebroad has quit IRC
2462016-12-16T10:50:25 *** murchandamus has joined #bitcoin-core-dev
2472016-12-16T10:52:17 *** murchandamus has quit IRC
2482016-12-16T10:54:13 <bitcoin-git> [bitcoin] laanwj opened pull request #9365: [testing] Dummy commit for checking travis failure (master...2016_12_debug_travis_issue) https://github.com/bitcoin/bitcoin/pull/9365
2492016-12-16T10:54:30 *** murchandamus has joined #bitcoin-core-dev
2502016-12-16T10:55:11 *** murchandamus has quit IRC
2512016-12-16T10:57:36 *** murchandamus has joined #bitcoin-core-dev
2522016-12-16T10:58:27 *** rebroad_ has quit IRC
2532016-12-16T10:59:18 *** murchandamus has quit IRC
2542016-12-16T10:59:53 *** MarcoFalke has joined #bitcoin-core-dev
2552016-12-16T11:00:13 <MarcoFalke> wumpus: The cause of test failure is most likely already known
2562016-12-16T11:00:53 <wumpus> MarcoFalke: what then?
2572016-12-16T11:01:20 <MarcoFalke> (see scrollback of yesterday evening)
2582016-12-16T11:01:28 <MarcoFalke> Might be some rounding in fee filter
2592016-12-16T11:01:48 <MarcoFalke> at the floor (i.e. minrelayfee)
2602016-12-16T11:02:15 <wumpus> can we work around this quicky to make travis pass again for unrelated pulls?
2612016-12-16T11:02:51 <MarcoFalke> Sure, I can try to settxfee in fundrawtx.py
2622016-12-16T11:03:14 <wumpus> reverting #9313 should help, then?
2632016-12-16T11:03:16 <gribble> https://github.com/bitcoin/bitcoin/issues/9313 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
2642016-12-16T11:04:03 <wumpus> it started yesterday and the only pull merged yesterday affecting fees/feefilters is that one
2652016-12-16T11:04:03 <MarcoFalke> Yes, would help.
2662016-12-16T11:04:32 <MarcoFalke> But I'd like to get it in in another form then
2672016-12-16T11:05:03 <wumpus> well we need a temporary workaround to make travis sane agian, we can always merge it again once this issue is solved
2682016-12-16T11:05:40 <MarcoFalke> ok, fine w/ me
2692016-12-16T11:05:43 <wumpus> anyhow going to try in #9365
2702016-12-16T11:05:45 <gribble> https://github.com/bitcoin/bitcoin/issues/9365 | [testing] [donotmerge] Dummy commit for checking travis failure by laanwj · Pull Request #9365 · bitcoin/bitcoin · GitHub
2712016-12-16T11:06:20 *** murchandamus has joined #bitcoin-core-dev
2722016-12-16T11:06:35 *** murchandamus has quit IRC
2732016-12-16T11:06:50 <wumpus> if travis will consistently pass with that reverted, I'm going to revert it on master too
2742016-12-16T11:07:26 <wumpus> in the mean time I've still managed to reproduce it locally 0 times - what makes this so special that it only happens on travis, I wonder
2752016-12-16T11:08:15 <wumpus> btw can anyone else get results from seed.bitcoin.sipa.be? it's been giving me nothing for something like two weeks now
2762016-12-16T11:08:38 <wumpus> but I've heard no one else compain about it
2772016-12-16T11:10:54 *** rebroad_ has joined #bitcoin-core-dev
2782016-12-16T11:12:48 <jonasschnelli> wumpus: we have a bug in the seeder somewhere...
2792016-12-16T11:12:52 <jonasschnelli> I couldn't track it down.
2802016-12-16T11:12:53 *** murchandamus has joined #bitcoin-core-dev
2812016-12-16T11:13:09 <jonasschnelli> Seems to be introduced with the filtering option
2822016-12-16T11:13:17 *** Victorsueca has joined #bitcoin-core-dev
2832016-12-16T11:13:27 <wumpus> jonasschnelli: okay - yes your testnet seed fails too
2842016-12-16T11:13:30 <jonasschnelli> Must be something with the cache... seeder is running but not results empty responses.
2852016-12-16T11:13:40 <jonasschnelli> (need to attach the debugger)
2862016-12-16T11:13:54 <jonasschnelli> But my long term plan is, to split the seeder in a crawler and a server
2872016-12-16T11:14:02 <jonasschnelli> As server, I'd like to use djbdns
2882016-12-16T11:14:10 <jonasschnelli> Shouldn't be that hard.
2892016-12-16T11:15:10 <wumpus> so it never returns results, or starts returning nothing after a while?
2902016-12-16T11:16:08 <wumpus> gah my dummy commit passed travis. Stupid heODODisenbug :)
2912016-12-16T11:16:20 <wumpus> heisenbug*
2922016-12-16T11:19:12 <btcdrak> wumpus: I also get no results from the seed, and I have complained about it on occasion
2932016-12-16T11:21:44 <MarcoFalke> wumpus: It should fail at most 25% of the time
2942016-12-16T11:24:47 *** murchandamus has quit IRC
2952016-12-16T11:25:59 *** murchandamus has joined #bitcoin-core-dev
2962016-12-16T11:27:40 <rebroad_> wumpus, my plan is to adapt the fingerprint test that (I presume) is already written to test that blocks cannot be fingerprinted - would you know which test file does that please? Is there a test already written to test fingerprint attacks at all?
2972016-12-16T11:28:16 *** Victorsueca has quit IRC
2982016-12-16T11:28:16 *** murchandamus has quit IRC
2992016-12-16T11:29:23 *** Victorsueca has joined #bitcoin-core-dev
3002016-12-16T11:41:20 <wumpus> btcdrak: okay, hadn't noticed then
3012016-12-16T11:41:49 <wumpus> MarcoFalke: that seems true on travis - but I'm running it locally in a loop, has run ~100 times or so, no failures
3022016-12-16T11:42:00 *** murchandamus has joined #bitcoin-core-dev
3032016-12-16T11:42:34 <wumpus> in any case #9365 seems to be consistently passing with #9313 reverted
3042016-12-16T11:42:36 <gribble> https://github.com/bitcoin/bitcoin/issues/9365 | [testing] [donotmerge] Dummy commit for checking travis failure by laanwj · Pull Request #9365 · bitcoin/bitcoin · GitHub
3052016-12-16T11:42:37 <gribble> https://github.com/bitcoin/bitcoin/issues/9313 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
3062016-12-16T11:43:27 <MarcoFalke> That is odd. I can no longer reproduce either. I surely saw it yesterday
3072016-12-16T11:44:21 <MarcoFalke> Nah, just failed
3082016-12-16T11:48:35 *** AaronvanW has quit IRC
3092016-12-16T11:49:52 <MarcoFalke> rebroad_: qa/rpc-tests/p2p-compactblocks.py
3102016-12-16T11:52:37 *** cannon-c has quit IRC
3112016-12-16T11:52:44 <rebroad_> MarcoFalke, I already checked that file - it seems to be a test for compact blocks - I was asking about the test that tests that old alt-chain full-blocks cannot be requested... this would be the closest to the test I want to create
3122016-12-16T11:53:09 <rebroad_> MarcoFalke, thanks though
3132016-12-16T11:53:44 <rebroad_> these python tests are new territory for me.. so a bit of a learning curve..
3142016-12-16T11:54:40 <rebroad_> my goodness the pruning test seems to take a while to run...
3152016-12-16T12:02:12 *** rebroad_ has quit IRC
3162016-12-16T12:10:00 *** AaronvanW has joined #bitcoin-core-dev
3172016-12-16T12:23:14 <bitcoin-git> [bitcoin] kallewoof closed pull request #9361: [WIP] Fix: OSX QT compile fix: defer to bswap_XX when defined. (master...macosx-qt-build-fix) https://github.com/bitcoin/bitcoin/pull/9361
3182016-12-16T12:25:43 <bitcoin-git> [bitcoin] kallewoof opened pull request #9366: Fix: OSX QT compile: use built-in swap if available, or defer (master...macosx-qt-build-fix2) https://github.com/bitcoin/bitcoin/pull/9366
3192016-12-16T12:28:21 *** e4xit has quit IRC
3202016-12-16T12:30:18 *** e4xit has joined #bitcoin-core-dev
3212016-12-16T12:30:48 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #9367: If we don't allow free txs, always send a fee filter (take 2) (master...Mf1612-feeFilterAlways2) https://github.com/bitcoin/bitcoin/pull/9367
3222016-12-16T12:44:03 *** Atomicat_ has joined #bitcoin-core-dev
3232016-12-16T12:45:37 *** Atomicat has quit IRC
3242016-12-16T12:45:45 *** Atomicat_ is now known as Atomicat
3252016-12-16T12:50:21 *** rebroad_ has joined #bitcoin-core-dev
3262016-12-16T13:11:48 <morcos> MarcoFalke: thanks... i just got a chance to sit down and look and i'd forgotten how fundrawtransaction sets exactly min_relay_tx_fee, but i think the way you fixed it makes the most sense.
3272016-12-16T13:17:16 *** rebroad_ has quit IRC
3282016-12-16T13:23:21 <phantomcircuit> wumpus, can you tell me about commit e8ef3da7 ?
3292016-12-16T13:23:23 <phantomcircuit> it's from 2011 so im not expecting much
3302016-12-16T13:23:35 <phantomcircuit> commit message is just "update core to d0d80170a2ca73004e08fb85007fe055cbf4e411 (CWallet class)"
3312016-12-16T13:25:51 <phantomcircuit> nvm i see i should actually be asking sipa maybe?
3322016-12-16T13:26:09 <phantomcircuit> nvm i see i should be asking s_nakamoto
3332016-12-16T13:26:11 <phantomcircuit> :/
3342016-12-16T13:45:43 *** jtimon has quit IRC
3352016-12-16T13:49:45 *** rebroad has joined #bitcoin-core-dev
3362016-12-16T13:50:16 <rebroad> gmaxwell, re this (https://botbot.me/freenode/bitcoin-core-dev/2016-12-15/?msg=78044110&page=4) - are you saying that one won't need a segwit wallet to spend a segwit tx?
3372016-12-16T13:50:32 *** MarcoFalke has left #bitcoin-core-dev
3382016-12-16T13:54:02 <instagibbs> this is a bit #bitcoin but rebroad, you only need a segwit wallet to spend segwit outputs that you receive... but by definition you won't ask for them and receive legacy payments
3392016-12-16T13:54:33 *** laurentmt has joined #bitcoin-core-dev
3402016-12-16T13:54:38 *** laurentmt has quit IRC
3412016-12-16T13:56:23 *** Giszmo has joined #bitcoin-core-dev
3422016-12-16T13:57:18 <rebroad> instagibbs, ah. yes, makes sense. thanks.
3432016-12-16T14:02:45 *** MarcoFalke has joined #bitcoin-core-dev
3442016-12-16T14:03:05 <rebroad> gmaxwell, did zander change his article or did you misquote it? the sentence "So if a person doesn't upgrade they will eventually not be able to accept money from anyone." does not appear to be in the URL you posted on here
3452016-12-16T14:04:40 *** MarcoFalke has left #bitcoin-core-dev
3462016-12-16T14:09:52 <bitcoin-git> [bitcoin] s-matthew-english opened pull request #9368: change to declarative sentences. simplify links (master...patch-13) https://github.com/bitcoin/bitcoin/pull/9368
3472016-12-16T14:18:52 <phantomcircuit> instagibbs, uh do you even need a segwit compatible wallet to spend segwit outputs?
3482016-12-16T14:18:55 <phantomcircuit> i didn't think you did
3492016-12-16T14:19:56 <phantomcircuit> i don't think you do actually
3502016-12-16T14:20:01 <Chris_Stewart_5> phantomcircuit: Pretty sure you do, you won't be able to construct the tx in the proper structure without it
3512016-12-16T14:20:02 <phantomcircuit> the utxo entries aren't changes
3522016-12-16T14:20:13 <phantomcircuit> changed*
3532016-12-16T14:20:38 <phantomcircuit> you'd have to know that there is a transaction output in the utxo to begin with
3542016-12-16T14:20:53 <phantomcircuit> but if you have someone providing you transactions with the signatures stripped in normal format
3552016-12-16T14:20:56 <Chris_Stewart_5> segwit P2WPKH outputs require a empty script sig, and P2WSH requires a push only scriptSig of 32 bytes i think
3562016-12-16T14:21:07 <phantomcircuit> ok?
3572016-12-16T14:21:07 <phantomcircuit> so
3582016-12-16T14:21:41 <phantomcircuit> you're talking about inputs not outputs
3592016-12-16T14:21:47 <phantomcircuit> which is what the person spending cares about
3602016-12-16T14:22:02 <phantomcircuit> i mean maybe it's not easy to do
3612016-12-16T14:22:08 <phantomcircuit> but you certainly should be able to
3622016-12-16T14:22:43 <Chris_Stewart_5> how doe thes person spending an output not care about the input? Isn't that by definition the inputs to the script program to make it evaluate to true?
3632016-12-16T14:23:43 <phantomcircuit> Chris_Stewart_5, why would they care about the inputs to a transaction they're spending the outputs of?
3642016-12-16T14:26:15 <Chris_Stewart_5> phantomcircuit: 'transactions stripped in normal format' -- so you mean someoen is just providing you a serialized tx to hash, then sign the hash?
3652016-12-16T14:33:34 <rebroad> phantomcircuit, if you have a non-segwit wallet, then you can spend any SegWit transaction... but it will never get mined :)
3662016-12-16T14:34:05 <rebroad> well, it could get mined by the 5% still on the non-segwit fork.. but would soon get orphaned
3672016-12-16T14:58:09 *** timothy has quit IRC
3682016-12-16T14:58:49 *** timothy has joined #bitcoin-core-dev
3692016-12-16T15:06:55 *** laurentmt has joined #bitcoin-core-dev
3702016-12-16T15:07:11 *** laurentmt has quit IRC
3712016-12-16T15:10:00 <phantomcircuit> rebroad, why?
3722016-12-16T15:10:22 <phantomcircuit> the scriptPubKey is the same right?
3732016-12-16T15:10:26 <phantomcircuit> wait maybe it's not
3742016-12-16T15:10:27 <phantomcircuit> hmm
3752016-12-16T15:11:03 <bitcoin-git> [bitcoin] ryanofsky opened pull request #9369: Factor out CWallet::nTimeSmart computation into a method. (master...pr/atw-timesmart) https://github.com/bitcoin/bitcoin/pull/9369
3762016-12-16T15:16:57 *** rebroad has quit IRC
3772016-12-16T15:17:57 *** windsok has quit IRC
3782016-12-16T15:20:28 *** Chris_Stewart_5 has quit IRC
3792016-12-16T15:20:59 *** jtimon has joined #bitcoin-core-dev
3802016-12-16T15:32:51 *** laurentmt has joined #bitcoin-core-dev
3812016-12-16T15:32:59 *** laurentmt has quit IRC
3822016-12-16T15:39:44 *** skyraider_ has joined #bitcoin-core-dev
3832016-12-16T15:43:34 <jonasschnelli> morcos: you once asked about a short description how the proposed spv-ish auxiliary block downloads works: https://github.com/bitcoin/bitcoin/pull/9171#issuecomment-267616678
3842016-12-16T15:44:40 *** rebroad has joined #bitcoin-core-dev
3852016-12-16T15:50:45 <bitcoin-git> [bitcoin] laanwj closed pull request #9365: [testing] [donotmerge] Dummy commit for checking travis failure (master...2016_12_debug_travis_issue) https://github.com/bitcoin/bitcoin/pull/9365
3862016-12-16T15:52:57 *** windsok has joined #bitcoin-core-dev
3872016-12-16T16:08:28 <phantomcircuit> rebroad, yeah i still dont see why you wouldn't be able to spend outputs from a segwit transactions with a normal transaction
3882016-12-16T16:08:38 <phantomcircuit> the only thing being changed is the serialization of the script
3892016-12-16T16:10:22 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c9e00591cd3f...8c7947e09ff8
3902016-12-16T16:10:22 <bitcoin-git> bitcoin/master fa16b8f MarcoFalke: If we don't allow free txs, always send a fee filter (take 2)
3912016-12-16T16:10:23 <bitcoin-git> bitcoin/master 8c7947e Wladimir J. van der Laan: Merge #9367: If we don't allow free txs, always send a fee filter (take 2)...
3922016-12-16T16:10:40 <bitcoin-git> [bitcoin] laanwj closed pull request #9367: If we don't allow free txs, always send a fee filter (take 2) (master...Mf1612-feeFilterAlways2) https://github.com/bitcoin/bitcoin/pull/9367
3932016-12-16T16:18:01 <instagibbs> phantomcircuit, if your wallet doesn't understand segwit, it has no idea how to sign, if nothing else
3942016-12-16T16:18:08 <instagibbs> (sorry missed convo)
3952016-12-16T16:19:25 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3962016-12-16T16:27:02 *** aalex has quit IRC
3972016-12-16T16:28:22 *** aalex has joined #bitcoin-core-dev
3982016-12-16T16:30:11 <rebroad> phantomcircuit, segwit as I understand is an extra bunch of rules that pre-segwit wallets have no knowledge of... pre-segwit wallets simply see segwit txs as txs that anyone can spend, so the only thing pre-segwit wallets can do is treat them as such, which segwit wallets and miners will reject as it ignores the segwit rules
3992016-12-16T16:33:25 <sipa> rebroad: no wallet does anything with outputs they do not understand
4002016-12-16T16:33:43 <sipa> *nodes* will treat those outputs as anyonecanspend, yes
4012016-12-16T16:33:48 <sipa> but wallets don't
4022016-12-16T16:34:13 <sipa> your wallet does not show you all anyonecanspend outputs on the network now, right?
4032016-12-16T16:34:58 <sipa> the only way you will receive a segwit output is if you give out a segwit address, which will only happen if your wallet supports it
4042016-12-16T16:35:52 <rebroad> sipa, well, nodes, and modified pre-segwit wallets ;)
4052016-12-16T16:36:05 <sipa> sure
4062016-12-16T16:36:17 <sipa> they can try
4072016-12-16T16:36:25 <sipa> but they won't confirm
4082016-12-16T16:36:51 <rebroad> sipa, if they did confirm, miners would build upon those blocks
4092016-12-16T16:37:06 <rebroad> at least, pre-segwit activation anyway
4102016-12-16T16:37:26 <rebroad> but people would have to be a little foolish to create such a tx pre-segwit
4112016-12-16T16:37:44 <sipa> pre-activation you shouldn't be creating segwit outputs
4122016-12-16T16:37:48 <sipa> that's very dangerois
4132016-12-16T16:41:50 *** face_ has joined #bitcoin-core-dev
4142016-12-16T16:42:05 <Victorsueca> creating a segwit transaction without miners and nodes enforcing segwit yet can potentially lead to anyone-can-spend outputs
4152016-12-16T16:43:06 <sipa> not potentially
4162016-12-16T16:43:18 <sipa> by definition, they will be anyonecanspend outputs
4172016-12-16T16:43:28 *** face_ is now known as face
4182016-12-16T16:45:24 <rebroad> they need to be anyonecanspend outputs for segwit to be possible
4192016-12-16T16:49:31 <Victorsueca> just had a quick thought about this....
4202016-12-16T16:51:18 <Victorsueca> let's say the last block in a 2016 block period is the one that decides if segwit activates in that moment or it will in the next period (or even, hopefully not, never)...
4212016-12-16T16:52:04 <Victorsueca> and with that block it reaches 95% required to activate it
4222016-12-16T16:52:31 <sipa> that's not possible
4232016-12-16T16:52:42 <sipa> there is another 2016 block before it activates
4242016-12-16T16:52:48 <Victorsueca> ahh right
4252016-12-16T16:53:03 <sipa> the 95% makes it go to the LOCKEDIN state
4262016-12-16T16:53:37 <Victorsueca> welp, that solves it pretty much
4272016-12-16T16:54:22 <Victorsueca> my quick thoughts don't make sense most of the times.... but last time one of them made sense it was a disaster
4282016-12-16T17:01:01 <bitcoin-git> [bitcoin] jonasschnelli opened pull request #9370: Fix fundrawtransactions address-reuse problem (master...2016/12/fix_frt_cop) https://github.com/bitcoin/bitcoin/pull/9370
4292016-12-16T17:11:43 <jonasschnelli> I would say that #9370 (or one of the alternative solutions) is a candidate for a 0.13.2 backport.
4302016-12-16T17:11:44 <gribble> https://github.com/bitcoin/bitcoin/issues/9370 | Fix fundrawtransactions address-reuse problem by jonasschnelli · Pull Request #9370 · bitcoin/bitcoin · GitHub
4312016-12-16T17:18:08 <phantomcircuit> instagibbs, you're signing the new transaction not the old one
4322016-12-16T17:18:37 <phantomcircuit> rebroad, that's not saying that the wallet needs to understand segwit
4332016-12-16T17:18:52 *** abpa has joined #bitcoin-core-dev
4342016-12-16T17:18:58 <phantomcircuit> just that it needs to get the utxo entries from somewhere other than the transaction data
4352016-12-16T17:19:24 <phantomcircuit> wait no
4362016-12-16T17:19:34 <phantomcircuit> the SIGNATURE isn't needed by the person spending
4372016-12-16T17:19:42 <phantomcircuit> yeah im 99.99% sure you're wrong
4382016-12-16T17:20:12 <phantomcircuit> sipa, segwit doesn't change the outputs at all, just the inputs with the signature
4392016-12-16T17:20:27 <phantomcircuit> or does it and i am just very tired and hungry
4402016-12-16T17:22:20 <sdaftuar> phantomcircuit: see BIP 141. segwit outputs are constructed differently than non-segwit outputs.
4412016-12-16T17:22:55 <phantomcircuit> hmm
4422016-12-16T17:23:02 * phantomcircuit goes to find a thermometer
4432016-12-16T17:26:16 <gmaxwell> rebroad: he changed the text, many times. Last I checked the current text was still wrong as heck.
4442016-12-16T17:28:02 <phantomcircuit> 101...
4452016-12-16T17:28:04 <phantomcircuit> ok then
4462016-12-16T17:29:19 <phantomcircuit> oh right
4472016-12-16T17:29:35 <Victorsueca> 101ºC?
4482016-12-16T17:29:56 <Victorsueca> ;)
4492016-12-16T17:30:13 <sipa> phantomcircuit: p2sh witness outputs are indistinguishable to the network from other p2sh outputs
4502016-12-16T17:30:38 <sipa> but they are distinguishable to the receiver... who either knows the redeemscript and how to spend it, or not
4512016-12-16T17:31:18 <phantomcircuit> sipa, it's the same as p2sh originally right
4522016-12-16T17:31:45 <phantomcircuit> and is because of the change to the signature hashing basically meaning it's a "new" script language
4532016-12-16T17:31:53 <Victorsueca> basically you can't know whether it is P2SH, P2WSH or P2WPKH until the outputs are redeemed
4542016-12-16T17:32:33 <sipa> phantomcircuit: new signature hashing, and it takes inputs from the witness rather than from the scriptSig directly
4552016-12-16T17:32:43 <Victorsueca> some extra privacy, that's always good
4562016-12-16T17:34:33 *** laurentmt has joined #bitcoin-core-dev
4572016-12-16T17:34:42 *** laurentmt has quit IRC
4582016-12-16T17:44:00 *** aalex has quit IRC
4592016-12-16T17:45:46 *** skyraider_ has quit IRC
4602016-12-16T17:47:56 *** aalex has joined #bitcoin-core-dev
4612016-12-16T17:54:43 *** MykelSIlver has joined #bitcoin-core-dev
4622016-12-16T18:11:42 *** rebroad has quit IRC
4632016-12-16T18:19:41 *** profall has joined #bitcoin-core-dev
4642016-12-16T18:19:54 <profall> Hello, what is the default rpcworkqueue on 13.1 ?
4652016-12-16T18:20:03 <profall> I want to increase it but I have no idea what the starting value is
4662016-12-16T18:25:34 *** wasi has quit IRC
4672016-12-16T18:30:31 *** jannes has quit IRC
4682016-12-16T18:30:40 *** wasi has joined #bitcoin-core-dev
4692016-12-16T18:31:17 <sipa> 16
4702016-12-16T18:31:31 <profall> Thank You
4712016-12-16T18:38:10 *** laurentmt has joined #bitcoin-core-dev
4722016-12-16T18:43:04 *** laurentmt has quit IRC
4732016-12-16T18:53:00 <gmaxwell> sipa: So the chainstate reindex without signature verification test with 300MB dbcache completed, entry-per-txout is ~25% _faster_ than master!
4742016-12-16T18:56:41 <sipa> gmaxwell: woah
4752016-12-16T18:56:52 <sipa> wasn't only 6% at some point during sync?
4762016-12-16T19:03:04 *** wasi has quit IRC
4772016-12-16T19:03:18 <gmaxwell> I was screwing up the comparison when I was giving you those figures.
4782016-12-16T19:05:03 <sipa> wasn't it around the same number for a 2000MB dbcache?
4792016-12-16T19:05:58 <sipa> anyway great... more work, now we need to investigate this idea further
4802016-12-16T19:07:51 *** grubles is now known as grubles__
4812016-12-16T19:08:04 *** wasi has joined #bitcoin-core-dev
4822016-12-16T19:09:59 *** matrix01 has joined #bitcoin-core-dev
4832016-12-16T19:10:25 <matrix01> Who can help to gave me a small amount of BTC or borow me some pm me thx!
4842016-12-16T19:14:33 <sipa> matrix01: for experimenting purpose, use a testnet faucet. otherwise: this is not a place for begging
4852016-12-16T19:22:27 *** paveljanik has joined #bitcoin-core-dev
4862016-12-16T19:27:29 <bitcoin-git> [bitcoin] morcos opened pull request #9371: Notify on removal (master...notifyOnRemoval) https://github.com/bitcoin/bitcoin/pull/9371
4872016-12-16T19:38:20 <gmaxwell> sipa: ~23% for 2000MB, so yes.
4882016-12-16T19:38:44 *** sipa has quit IRC
4892016-12-16T19:38:44 *** sipa has joined #bitcoin-core-dev
4902016-12-16T19:42:39 *** wvr has joined #bitcoin-core-dev
4912016-12-16T19:47:23 <Lightsword> was the networking code being reworked to use libevent or something similar? or was that just the rpc server stuff?
4922016-12-16T19:48:23 <sipa> it's being reworked slowly
4932016-12-16T19:48:27 <sipa> but it's not yet using libevent
4942016-12-16T19:48:44 <sipa> but having the network code use libevent is indeed a goal
4952016-12-16T19:52:12 <Lightsword> is the network refactoring in preparation for that? how close is it to being able to use libevent?
4962016-12-16T19:52:28 <sipa> talk to cfields
4972016-12-16T19:52:36 <sipa> i expect libevent to happen in 0.15
4982016-12-16T19:53:30 <cfields> Lightsword: quite close, up and running locally. Upstreaming in chunks.
4992016-12-16T19:54:37 *** MykelSIlver has quit IRC
5002016-12-16T20:00:04 <matrix01> Who can help to gave me a small amount of BTC or borow me some pm me thx!
5012016-12-16T20:00:17 <sipa> matrix01: stop begging. last warning
5022016-12-16T20:00:28 *** ChanServ sets mode: +o sipa
5032016-12-16T20:06:01 *** matrix01 has left #bitcoin-core-dev
5042016-12-16T20:07:17 *** jtimon has quit IRC
5052016-12-16T20:12:12 *** Atomicat_ has joined #bitcoin-core-dev
5062016-12-16T20:14:26 *** Atomicat has quit IRC
5072016-12-16T20:14:33 *** Atomicat_ is now known as Atomicat
5082016-12-16T20:20:31 *** Guyver2 has quit IRC
5092016-12-16T20:28:34 <instagibbs> sipa, he's been doing this under various names repeatedly on other channels someone banhammer him
5102016-12-16T20:32:57 <bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8c7947e09ff8...b99a093afed8
5112016-12-16T20:32:58 <bitcoin-git> bitcoin/master ed58969 Pieter Wuille: Batch construct batches...
5122016-12-16T20:32:58 <bitcoin-git> bitcoin/master b99a093 Pieter Wuille: Merge #9346: Batch construct batches...
5132016-12-16T20:33:14 <bitcoin-git> [bitcoin] sipa closed pull request #9346: Batch construct batches (master...reusebatch) https://github.com/bitcoin/bitcoin/pull/9346
5142016-12-16T20:48:31 *** MykelSIlver has joined #bitcoin-core-dev
5152016-12-16T20:56:37 *** MykelSIlver has quit IRC
5162016-12-16T21:08:18 *** wvr has quit IRC
5172016-12-16T21:13:24 *** jtimon has joined #bitcoin-core-dev
5182016-12-16T21:27:25 <gmaxwell> https://github.com/bitcoin/bitcoin/graphs/contributors?from=2015-12-16&to=2016-12-16&type=c < anyone know why this doesn't list 2/3rds of the people who have contributed?
5192016-12-16T21:28:38 <achow101> date range is wrong?
5202016-12-16T21:31:10 <gmaxwell> Hm? git log --no-merges shows commits from ~150 contributors (some name dupes) from 2015-12-16 to now.
5212016-12-16T21:33:02 *** owowo has quit IRC
5222016-12-16T21:33:36 <arubi> replacing 'type=c' with a mock 'type=none' lists 100 people
5232016-12-16T21:37:18 <achow101> maybe some of the authors don't have their emails registered with github so they aren't shown?
5242016-12-16T21:40:16 <achow101> they might also be counting committers and not authors
5252016-12-16T21:42:20 <gmaxwell> achow101: nope, far too many.
5262016-12-16T21:42:40 <gmaxwell> achow101: e.g. you're listed.
5272016-12-16T21:43:06 <btcdrak> sounds like we need to report this to github, their data processing appears to be bugged
5282016-12-16T21:43:37 <achow101> well I made commits. there are some commits that are like "X committed with Y" so they might be counting that commit as made by Y and not X
5292016-12-16T21:44:03 <gmaxwell> achow101: yea, no-- not that either.
5302016-12-16T21:44:17 <gmaxwell> there are people not listed that made PRs and had them merged.
5312016-12-16T21:45:19 *** owowo has joined #bitcoin-core-dev
5322016-12-16T21:46:24 <Chris_Stewart_5> gmaxwell: I've noticed this with other repos, such as bitcoin-dot-org -- here is a pull request I had merged https://github.com/bitcoin-dot-org/bitcoin.org/pull/1333
5332016-12-16T21:46:39 <Chris_Stewart_5> but I'm not on the contributors list :/ not sure why
5342016-12-16T21:49:05 <achow101> gmaxwell: are you sure? even though they opened PRs, some of them have the committer name as someone else or committed on GitHub
5352016-12-16T21:49:52 <gmaxwell> achow101: https://github.com/bitcoin/bitcoin/pull/6842 take that one for example.
5362016-12-16T21:50:15 <achow101> that commit is out of your time range
5372016-12-16T21:53:05 <gmaxwell> achow101: ah it's merge isn't. Lemme find another.
5382016-12-16T21:57:34 <gmaxwell> https://github.com/bitcoin/bitcoin/commit/8c1dbc5e9ddbafb77e60e8c4e6eb275a3a76ac12 < how about that?
5392016-12-16T21:58:10 <achow101> no registered email with github
5402016-12-16T22:00:05 <gmaxwell> okay, lemme try another!
5412016-12-16T22:01:09 <gmaxwell> yea, that might be it.
5422016-12-16T22:02:13 <achow101> gmaxwell: here's an example of a commit I was talking about: https://github.com/bitcoin/bitcoin/commit/203e2ddad8e544803491d1e9e9ca2b6e26a15f8e
5432016-12-16T22:02:21 <achow101> laudaa is not even in the contributors list at all
5442016-12-16T22:18:55 *** laurentmt has joined #bitcoin-core-dev
5452016-12-16T22:31:03 *** laurentmt has quit IRC
5462016-12-16T22:44:41 *** MykelSIlver has joined #bitcoin-core-dev
5472016-12-16T23:01:20 *** Madars has quit IRC
5482016-12-16T23:06:19 <sipa> morcos: any reason why ApplyTxInUndo can't use ModifyNewCoins?
5492016-12-16T23:07:01 *** sipa sets mode: -o sipa
5502016-12-16T23:11:14 *** alpalp has joined #bitcoin-core-dev
5512016-12-16T23:11:14 *** alpalp has joined #bitcoin-core-dev
5522016-12-16T23:22:37 *** alpalp has quit IRC
5532016-12-16T23:29:32 *** Madars has joined #bitcoin-core-dev
5542016-12-16T23:33:35 <morcos> sipa: you mean for the case where it's the last spend (undo.nHeight != 0)? I'm not sure I see how it would be any nicer..
5552016-12-16T23:36:34 <sipa> morcos: right, i was working on my per-txout branch... where it would apply for every spend
5562016-12-16T23:36:52 <sipa> i mean: would it be safe to use?
5572016-12-16T23:37:00 <morcos> heh, well then its a bit of a different question..
5582016-12-16T23:38:13 *** Madars has quit IRC
5592016-12-16T23:38:15 <morcos> i'd have to think about exactly how it works in a per-txout world.. but it seems like it should be.
5602016-12-16T23:39:03 <sipa> assuming your database is not corrupted, the undo data is trusted
5612016-12-16T23:39:19 *** dgenr8 has quit IRC
5622016-12-16T23:39:27 <sipa> which means that you are certain that it (semantically speaking, from the chain point of view) is never overwriting anything
5632016-12-16T23:40:27 *** dgenr8 has joined #bitcoin-core-dev
5642016-12-16T23:47:27 <morcos> yep, and at least after #9107 ModifyNewCoins asserts that that is the case
5652016-12-16T23:47:29 <gribble> https://github.com/bitcoin/bitcoin/issues/9107 | Safer modify new coins by morcos · Pull Request #9107 · bitcoin/bitcoin · GitHub