1 2016-05-06 01:27:18	0|GitHub63|[13bitcoin] 15wtogami opened pull request #8013: doc: Fedora build requirements, add gcc-c++ and fix typo (06master...06fedora_build_readme2) 02https://github.com/bitcoin/bitcoin/pull/8013
  2 2016-05-06 03:02:44	0|luke-jr|warren: I see no valid use case for that patch…
  3 2016-05-06 03:05:53	0|luke-jr|morcos: right now, GBT is broken in 0.12.1 due to BIP9
  4 2016-05-06 03:06:53	0|luke-jr|cfields: there is a PR for the GBT BIP9 changes already
  5 2016-05-06 03:07:04	0|luke-jr|if that's what you were asking
  6 2016-05-06 03:09:37	0|warren|luke-jr: I think it exposes the change address that is configurable in the coin control GUI
  7 2016-05-06 03:10:11	0|luke-jr|warren: once per startup, which makes no sense unless you're starting bitcoind JUST to send once
  8 2016-05-06 03:10:30	0|warren|luke-jr: right, which is why Matt thought it made more sense as an RPC option
  9 2016-05-06 03:10:38	0|luke-jr|yeah, probably
 10 2016-05-06 03:10:46	0|warren|in any case it isn't my problem
 11 2016-05-06 03:10:51	0|luke-jr|I *think* There's a PR open for it too
 12 2016-05-06 03:10:56	0|warren|oh?
 13 2016-05-06 03:12:26	0|luke-jr|https://github.com/bitcoin/bitcoin/pull/7518
 14 2016-05-06 03:14:29	0|warren|That doesn't help sendtoaddress right?
 15 2016-05-06 03:14:48	0|luke-jr|of course not, it doesn't make sense for sendtoaddress
 16 2016-05-06 03:14:56	0|luke-jr|sendtoaddress is a simple RPC for normal users
 17 2016-05-06 03:15:04	0|luke-jr|normal users should never be messing with change addresses
 18 2016-05-06 03:17:36	0|sipa|for fundrawtransaction it may make sense
 19 2016-05-06 03:17:44	0|sipa|(i'm surprised it doesn't already have it?0
 20 2016-05-06 03:17:50	0|luke-jr|yes, that's what the PR does
 21 2016-05-06 03:18:28	0|luke-jr|note it is merged
 22 2016-05-06 03:30:52	0|warren|In discussion with cfields today we decided it would be nice and not too difficult to improve the makefiles and gitian such that "make rpm" and "make deb" would work and be used during the ordinary gitian-linux process.  It can spit out deterministic deb and rpm's during the existing gitian build process.  They can be subsequently GPG signed in a similar manner to the OSX and Windows installers.
 23 2016-05-06 03:32:45	0|warren|After this is done I will make the recommendation to Fedora that they do NOT want to build and maintain their own Bitcoin RPM, mostly because they EOL distros very quickly and people will be stuck with old versions of Bitcoin.  Installing Bitcoin should be a conscious process not subject to auto-update either.
 24 2016-05-06 03:40:17	0|GitHub1|[13bitcoin] 15Tyler-Hardin opened pull request #8014: Qt: Sort transactions by date (06master...06sort-by-date) 02https://github.com/bitcoin/bitcoin/pull/8014
 25 2016-05-06 03:55:48	0|luke-jr|warren: how will that deal with ABI issues between distros?
 26 2016-05-06 04:16:22	0|GitHub62|[13bitcoin] 1521E14 opened pull request #8015: CCoinsViewErrorCatcher raison-d-etre (06master...06wrapper) 02https://github.com/bitcoin/bitcoin/pull/8015
 27 2016-05-06 06:04:09	0|warren|luke-jr: you don't, the gitian build contains static libraries
 28 2016-05-06 06:04:41	0|warren|If you use "make rpm" or "make deb" on your own distro you get a dynamic binary.
 29 2016-05-06 08:03:28	0|GitHub138|13bitcoin/06master 1499e7075 15Wladimir J. van der Laan: Break circular dependency main ↔ txdb...
 30 2016-05-06 08:03:28	0|GitHub138|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/006cdf64dc93...efee32f38110
 31 2016-05-06 08:03:29	0|GitHub138|13bitcoin/06master 14efee32f 15Wladimir J. van der Laan: Merge #7815: Break circular dependency main ↔ txdb...
 32 2016-05-06 08:03:33	0|GitHub95|[13bitcoin] 15laanwj closed pull request #7815: Break circular dependency main ↔ txdb (06master...062016_04_break_txdb_main_dep) 02https://github.com/bitcoin/bitcoin/pull/7815
 33 2016-05-06 08:04:29	0|GitHub58|13bitcoin/06master 14e53e7c5 15Kaz Wesley: don't run ThreadMessageHandler at lowered priority...
 34 2016-05-06 08:04:29	0|GitHub58|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/efee32f38110...65aecda52d0d
 35 2016-05-06 08:04:30	0|GitHub58|13bitcoin/06master 1465aecda 15Wladimir J. van der Laan: Merge #8011: don't run ThreadMessageHandler at lowered priority...
 36 2016-05-06 08:04:39	0|GitHub178|[13bitcoin] 15laanwj closed pull request #8011: don't run ThreadMessageHandler at lowered priority (06master...06priority) 02https://github.com/bitcoin/bitcoin/pull/8011
 37 2016-05-06 08:32:11	0|jonasschnelli|Is that only my observation? A full sync with BitcoinD is much faster then with Bitcoin-Qt?
 38 2016-05-06 08:32:19	0|jonasschnelli|Doing measurements now.
 39 2016-05-06 08:50:32	0|paveljanik|some UI locks?
 40 2016-05-06 08:53:27	0|jonasschnelli|paveljanik: probably. But it feels like losing 50% of the sync "performance". Will have some ~numbers soon.
 41 2016-05-06 08:54:04	0|paveljanik|50% is a bit too much, yes.
 42 2016-05-06 09:10:38	0|GitHub170|[13bitcoin] 15paveljanik opened pull request #8016: Fix multithread CScheduler and reenable test (06master...0620160506_multithread_CScheduler) 02https://github.com/bitcoin/bitcoin/pull/8016
 43 2016-05-06 09:22:05	0|GitHub19|[13bitcoin] 15jonasschnelli closed pull request #7830: [Wallet] Add cloned wallet, remove accounts, reset version (06master...062016/04/wallet2) 02https://github.com/bitcoin/bitcoin/pull/7830
 44 2016-05-06 09:24:47	0|GitHub83|13bitcoin/06master 14fa389d4 15MarcoFalke: [qa] Switch to py3
 45 2016-05-06 09:24:47	0|GitHub83|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/65aecda52d0d...77b637f20e8c
 46 2016-05-06 09:24:48	0|GitHub83|13bitcoin/06master 1477b637f 15Wladimir J. van der Laan: Merge #7814: [qa] Switch to py3...
 47 2016-05-06 09:24:52	0|GitHub87|[13bitcoin] 15laanwj closed pull request #7814: [qa] Switch to py3 (06master...06Mf1604-qaPy3) 02https://github.com/bitcoin/bitcoin/pull/7814
 48 2016-05-06 09:51:54	0|paveljanik|MarcoFalke, python3: httplib not found -> http.client?
 49 2016-05-06 09:52:23	0|MarcoFalke|You need to check out the specific commit
 50 2016-05-06 09:52:40	0|MarcoFalke|git checkout fa6cd636c05fa18afbfc35e4e8ad0e7e69c0ae35
 51 2016-05-06 09:52:50	0|paveljanik|yup, already known
 52 2016-05-06 09:53:05	0|paveljanik|I'm 5 minutes late after fanquake ;-)
 53 2016-05-06 09:53:09	0|paveljanik|I'll wait :-)
 54 2016-05-06 10:25:05	0|MarcoFalke|So why does travis fail all pulls with ImportError: No module named 'zmq'?
 55 2016-05-06 10:25:47	0|paveljanik|MarcoFalke, python-qmz not installed.
 56 2016-05-06 10:26:05	0|paveljanik|I'm just about to write to you, that we should make a conditional in the zmq tests to prevent this ;-)
 57 2016-05-06 10:26:50	0|paveljanik|README.md contains: sudo apt-get install python-zmq
 58 2016-05-06 10:27:43	0|paveljanik|and of course install this module in travis
 59 2016-05-06 10:30:32	0|MarcoFalke|https://github.com/bitcoin/bitcoin/blob/65aecda52d0d2179f77d675dc305225a1566c48f/.travis.yml#L46 https://github.com/bitcoin/bitcoin/blob/77b637f20e8cb91cf007bf416b603ca362385cdb/.travis.yml#L46
 60 2016-05-06 10:30:48	0|MarcoFalke|It is installed
 61 2016-05-06 10:30:54	0|MarcoFalke|Am I missing something?
 62 2016-05-06 10:34:33	0|paveljanik|Is there a log from the travis initialization to check?
 63 2016-05-06 10:35:49	0|paveljanik|and is there such module available at all? ;-)
 64 2016-05-06 10:36:07	0|MarcoFalke|Oh the cache is messed up
 65 2016-05-06 10:36:25	0|MarcoFalke|It fetches from master (which is py3) but the pulls are still py2
 66 2016-05-06 10:36:28	0|MarcoFalke|Just a guess
 67 2016-05-06 10:39:00	0|paveljanik|yes, maybe.
 68 2016-05-06 10:41:20	0|paveljanik|Does it help to rebase such PR?
 69 2016-05-06 10:42:03	0|GitHub91|[13bitcoin] 15jonasschnelli opened pull request #8018: Autofind rpc tests --srcdir (06master...062016/05/fix_test_srcdir) 02https://github.com/bitcoin/bitcoin/pull/8018
 70 2016-05-06 10:42:21	0|MarcoFalke|I am trying to avoid rebase but, hmm
 71 2016-05-06 10:43:37	0|paveljanik|ah
 72 2016-05-06 10:44:24	0|MarcoFalke|rebased
 73 2016-05-06 12:27:28	0|jonasschnelli|I was wrong. Bitcoin-Qt full sync takes ~ same amount of time as it takes with bitcoind.
 74 2016-05-06 13:46:22	0|wumpus|jonasschnelli: phew :)
 75 2016-05-06 13:47:06	0|wumpus|I'd understand if it is somewhat slower, I mean a GUI thread does produce some extra load, but doubling the time is absurd
 76 2016-05-06 13:49:26	0|GitHub17|13bitcoin/06master 14b3d18ba 15Warren Togami: doc: Fedora build requirements, add gcc-c++ and fix typo
 77 2016-05-06 13:49:26	0|GitHub17|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/77b637f20e8c...fbedc09b2d09
 78 2016-05-06 13:49:27	0|GitHub17|13bitcoin/06master 14fbedc09 15Wladimir J. van der Laan: Merge #8013: doc: Fedora build requirements, add gcc-c++ and fix typo...
 79 2016-05-06 13:49:36	0|GitHub171|[13bitcoin] 15laanwj closed pull request #8013: doc: Fedora build requirements, add gcc-c++ and fix typo (06master...06fedora_build_readme2) 02https://github.com/bitcoin/bitcoin/pull/8013
 80 2016-05-06 13:57:24	0|wumpus|looks like there are some travis failures regarding zmq https://travis-ci.org/bitcoin/bitcoin/jobs/128251961
 81 2016-05-06 13:57:52	0|MarcoFalke|It is some travis issue if you ask me
 82 2016-05-06 13:58:23	0|wumpus|seems likely, as it doesn't seem to be consistent
 83 2016-05-06 14:01:19	0|MarcoFalke|It is consistent for all pulls that were in the travis queue at the time the py3 pull was merged
 84 2016-05-06 14:01:32	0|MarcoFalke|Some broken cache logic, probably
 85 2016-05-06 14:36:27	0|luke-jr|warren: well then you haven't eliminated the reason for distros to package it..
 86 2016-05-06 15:25:39	0|GitHub137|13bitcoin/06master 14b06f6a9 15JeremyRand: Fixed invalid example paths in gitian-building.md...
 87 2016-05-06 15:25:39	0|GitHub137|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/fbedc09b2d09...fbd84788e676
 88 2016-05-06 15:25:40	0|GitHub137|13bitcoin/06master 14fbd8478 15Wladimir J. van der Laan: Merge #8009: Docs: Fixed invalid example paths in gitian-building.md...
 89 2016-05-06 15:25:50	0|GitHub195|[13bitcoin] 15laanwj closed pull request #8009: Docs: Fixed invalid example paths in gitian-building.md (06master...06doc-gitian-building-offline-paths-fix) 02https://github.com/bitcoin/bitcoin/pull/8009
 90 2016-05-06 16:30:43	0|maaku|I saw in the meeting logs that a back dated start date for segwit on testnet was accepted
 91 2016-05-06 16:31:06	0|maaku|This potentially causes severe problems for people who are doing ongoing integration testing of their own services on testnet
 92 2016-05-06 16:31:41	0|maaku|I hope that this decision is reconsidered (or a delay to activation is added)
 93 2016-05-06 16:31:51	0|jl2012|maaku, I think BIP68 also backdated?
 94 2016-05-06 16:32:02	0|maaku|jl2012: which was also a mistake
 95 2016-05-06 16:33:01	0|maaku|the delay can be short, e.g. a few weeks. but it shouldn't be zero
 96 2016-05-06 16:33:44	0|maaku|that is placing a potential forking situation on people who have been absorbed in their own work, with absolutely no warning
 97 2016-05-06 16:36:16	0|jl2012|you mean some people are already testing segwit on testnet?
 98 2016-05-06 16:39:59	0|maaku|jl2012: I mean that with a back-dated start date segwit could activate within hours if someone decided to throw some hash power at it
 99 2016-05-06 16:40:55	0|jl2012|same before we had bip9
100 2016-05-06 16:40:55	0|maaku|wihch is not unlikely
101 2016-05-06 16:41:08	0|maaku|jl2012: ...
102 2016-05-06 16:41:25	0|maaku|because we fucked up in the past does not mean we should continue to be fuckups
103 2016-05-06 16:41:56	0|maaku|set a data of May 15th or something and make a loud announcement, so people have at least a little bit of time to make sure they're not affected
104 2016-05-06 16:46:01	0|sipa|maaku: that's reasonable, but testnet is always subject to wide hashrate swings and forks
105 2016-05-06 16:46:54	0|sipa|and it's not like the code for segwit is merged... there isn't even a branch with those activation times included at this point
106 2016-05-06 16:47:42	0|maaku|yeah but still, we should try not to add to the noise
107 2016-05-06 16:57:42	0|sipa|sdaftuar: do you think there are pitfalls when converted the txid index of CTxMempool:mapTx to a hashed-based one?
108 2016-05-06 17:00:00	0|sdaftuar|sipa: hmm, i'm not sure i sufficiently explored it, but i don't recall thinking it would be problematic
109 2016-05-06 17:00:25	0|sipa|i remember trying, and failing
110 2016-05-06 17:00:36	0|sdaftuar|yeah so probably i was missing something then :)
111 2016-05-06 17:01:24	0|sdaftuar|maybe kazcw wants to take a stab at it!  the setSpends thing is cool
112 2016-05-06 17:28:29	0|GitHub166|[13bitcoin] 15instagibbs opened pull request #8019: Remove state arg from ReconsiderBlock (06master...06reblarg) 02https://github.com/bitcoin/bitcoin/pull/8019
113 2016-05-06 18:00:00	0|jl2012|maaku, no matter what we do, when no one is mining, an attacker can easily fork the network by mining a long non-segwit chain after activation
114 2016-05-06 18:00:36	0|jl2012|unless we have hashrate to keep the chain growing, which is burning money
115 2016-05-06 18:04:33	0|BlueMatt|any ideas
116 2016-05-06 18:04:33	0|BlueMatt|hmmm...sipa so I need to keep around a list of node pointers I can send messages to in main.cpp...would be a huge shame to put CNode* back in logic there :/
117 2016-05-06 18:04:33	0|BlueMatt|or, wait, who introduced NodeId
118 2016-05-06 18:07:25	0|gmaxwell|jl2012: maaku's concern is that you we should give people time to update so their nodes will ignore that fork.
119 2016-05-06 18:07:33	0|gmaxwell|I don't share the concern.
120 2016-05-06 18:08:02	0|gmaxwell|(or rather, I share it but believe that we will end up giving them adequate time, without having to delay further.)
121 2016-05-06 18:09:51	0|jl2012|i hope to see it live on testnet as early as possible, so we could start testing the dynamics of upgraded and non-upgraded nodes
122 2016-05-06 18:10:22	0|jl2012|and I'm sure it will be attacked, intentionally or unintentionally
123 2016-05-06 18:11:09	0|jl2012|unless we keep mining it
124 2016-05-06 18:11:38	0|gmaxwell|jl2012: if nodes are already upgraded to enforce, then _full nodes_ (which is 99% of what exists on testnet) won't notice any such attack.
125 2016-05-06 18:12:35	0|jl2012|but the point to test it on testnet is to examine the interaction between upgraded and non-upgraded nodes
126 2016-05-06 18:12:48	0|jl2012|if we just want upgraded nodes, we already have segnet
127 2016-05-06 18:14:48	0|jl2012|and if upgraded nodes have minority hashrate, we are actually implementing a segnet under the name of testnet
128 2016-05-06 18:14:55	0|instagibbs|jl2012, you can do that in segnet too
129 2016-05-06 18:15:38	0|gmaxwell|we can also spin up a new testnet that is mixed.
130 2016-05-06 18:16:02	0|gmaxwell|which would not disrupt other people's testing that is unrelated to segwit.
131 2016-05-06 18:17:18	0|jl2012|actually I'm running a non-upgraded node on the segwit. Probably the only one
132 2016-05-06 18:20:51	0|sipa|BlueMatt: i introduced nodeid
133 2016-05-06 18:22:04	0|sipa|BlueMatt: but perhaps net can have a function to send a particular message to a list of nodeids
134 2016-05-06 18:22:56	0|sipa|BlueMatt: alternatively, you can keep a list of CNode* pointers around, but you'll need cleanup logic in FinalizeNode to remove any reference to a node when it disappears
135 2016-05-06 18:24:23	0|BlueMatt|sipa: yea, I mean i was thinking about CNode* references...but that kinda defeats the purpose of NodeId
136 2016-05-06 18:24:29	0|BlueMatt|sipa: in fact, any solution kinda defeats the purpose of NodeId...might as well kill NodeId if we have back-and-forward references between CNodes and NodeIds
137 2016-05-06 18:31:39	0|sipa|BlueMatt: i disagree
138 2016-05-06 18:31:45	0|sipa|BlueMatt: net should not expose CNode
139 2016-05-06 18:31:55	0|sipa|and only expose abstract identifiers
140 2016-05-06 18:32:25	0|sipa|the fact that you need back-and-forth references is a side effect of the logic now being split between net and main
141 2016-05-06 18:33:37	0|BlueMatt|sipa: so you mean that we /should/ have an interface to send to a nodeid, because we shouldn't expose CNode at all, and pfrom should, in fact, be a nodeid?
142 2016-05-06 18:33:45	0|sipa|BlueMatt: yup
143 2016-05-06 18:34:09	0|sipa|but i expect that code to undergo very significant changes after cory's net changes
144 2016-05-06 18:34:43	0|BlueMatt|meh, I mean /all/ processing should happen in net imo...the fact that main knows /anything/ about the p2p protocol is bad
145 2016-05-06 18:34:44	0|BlueMatt|but, indeed, its kinda all up in the air as cory refactors net
146 2016-05-06 18:35:15	0|BlueMatt|I'll add a CNode* ref for now, with the expectation that it will dissapear soonish
147 2016-05-06 18:36:49	0|sdaftuar|sipa: fyi, according to morcos it worked relatively easily to convert mapTx's txid index to an unordered_map.
148 2016-05-06 18:37:14	0|sipa|sdaftuar: oh, sorry to not report back; yes, it was trivial :)
149 2016-05-06 18:37:28	0|sipa|doing it as part of a slighly larger change
150 2016-05-06 18:37:35	0|sdaftuar|cool!
151 2016-05-06 20:01:25	0|GitHub88|[13bitcoin] 15sipa opened pull request #8020: Use SipHash-2-4 for various non-cryptographic hashes (06master...06siphash) 02https://github.com/bitcoin/bitcoin/pull/8020
152 2016-05-06 20:34:38	0|phantomcircuit|sipa: why the macro implementation?
153 2016-05-06 20:39:39	0|sipa|phantomcircuit: copy paste
154 2016-05-06 20:39:53	0|sipa|sugfestion for something better
155 2016-05-06 20:41:16	0|phantomcircuit|sipa: that was my guess, no suggestion at the moment
156 2016-05-06 20:43:22	0|phantomcircuit|sipa: is it safe to use hashed_unique like that in the mempool code?
157 2016-05-06 20:43:39	0|phantomcircuit|well i guess it is in so much as a collision just means you're missing a tx from the mempool
158 2016-05-06 20:53:35	0|sipa|phantomcircuit: the key for the mempool is still full txid
159 2016-05-06 20:54:17	0|sipa|the 64-bit hash is just internally used in the multi_index implementation, to decide what bucket an entry goes into
160 2016-05-06 20:54:26	0|sipa|but buckets can hold multiple items without problems
161 2016-05-06 21:08:49	0|phantomcircuit|sipa: ah ok, that's not clear from just the diff guess i needed more context
162 2016-05-06 21:09:25	0|phantomcircuit|ah right the thing "really" being indexed is CTxMemPoolEntry