1 2015-04-07 00:20:05 <phantomcircuit> andytoshi, ^
  2 2015-04-07 00:20:28 <phantomcircuit> looking for feedback on fixing the address trickling behavior
  3 2015-04-07 00:21:46 <andytoshi> hmm, that all -sounds- reasonable..
  4 2015-04-07 00:23:30 <andytoshi> "with the list of peers changing only when the peers addrman has changes also" can't the peer cause this to happen and still get a dump?
  5 2015-04-07 00:23:53 <andytoshi> or would he need to create a new connection from somewhere else?
  6 2015-04-07 00:25:34 <phantomcircuit> andytoshi, actually thinking about it more I dont see how we can reasonably prevent an attacker from dumping the entire list of known peers
  7 2015-04-07 00:26:16 <andytoshi> well if you can fingerprint the peer somehow then do what you said where you give a fixed list per fingerprint
  8 2015-04-07 00:26:26 <andytoshi> ofc, an attacker with a botnet can still evade this
  9 2015-04-07 00:26:27 <phantomcircuit> we'd have to only share a small fraction of the known peers with each peer otherwise a sybil attack would be trivial
 10 2015-04-07 00:26:56 <andytoshi> also it's really not obvious to me what global effect that would have on network topology
 11 2015-04-07 00:28:17 <andytoshi> maybe we do something like the fortuna entropy pool, where we have a small pool of addrs that we give to peers
 12 2015-04-07 00:28:39 <andytoshi> and every N getaddrs we cycle that pool with a bigger pool, every N^2 we cycle with an even bigger pool, etc
 13 2015-04-07 00:28:52 <andytoshi> so the attacker would have to operate for an exponential amount of time to learn the entire pool
 14 2015-04-07 00:28:53 <phantomcircuit> every n seconds would probably work better
 15 2015-04-07 00:28:57 <andytoshi> yeah :P
 16 2015-04-07 00:29:41 <andytoshi> actually, i think that's silly, it'd have the same effect as putting a binomial distribution on the pool
 17 2015-04-07 00:29:55 <andytoshi> "these peers i reveal with probability 1/N, these ones probability 1/N^2, etc"
 18 2015-04-07 00:29:57 <phantomcircuit> hmm maybe going back to the goal would help
 19 2015-04-07 00:30:02 <andytoshi> right
 20 2015-04-07 00:30:16 <phantomcircuit> the goal is to prevent an attacker from identifying which nodes are connected
 21 2015-04-07 00:30:58 <phantomcircuit> by connecting to all the peers the attacker can find and watching for addr broadcasts an attacker can identify which nodes a peer is connected to
 22 2015-04-07 00:33:02 <andytoshi> by seeing which nodes broadcast that they know that peer?
 23 2015-04-07 00:33:11 <andytoshi> or by badgering the peer itself?
 24 2015-04-07 00:33:29 <phantomcircuit> andytoshi, nominally the first
 25 2015-04-07 00:33:51 <phantomcircuit> but if you badger all of the peers which can accept inbound connections you can simulate that
 26 2015-04-07 00:34:06 <phantomcircuit> which you can actually do today for a few hundred usd/month
 27 2015-04-07 00:34:18 <phantomcircuit> it end sup being maybe 200mbps
 28 2015-04-07 00:35:34 <andytoshi> ok, so maybe addr broadcasts should use a small pool which prioritizes peers which aren't seen too often
 29 2015-04-07 00:35:51 <andytoshi> with the goal that all peers get noticed, but individual peers aren't broadcasting many
 30 2015-04-07 00:36:17 <andytoshi> that seems hard to game, it's hard to convince a peer that some target -isn't- being seen
 31 2015-04-07 00:37:04 <phantomcircuit> andytoshi, define seen
 32 2015-04-07 00:37:36 <andytoshi> "appears in someone else's addr broadcast, or in a response to getaddr"
 33 2015-04-07 00:37:45 <phantomcircuit> ok
 34 2015-04-07 00:38:32 <phantomcircuit> hmm
 35 2015-04-07 00:38:51 <andytoshi> hmm is right, it's hard to think about
 36 2015-04-07 00:39:58 <phantomcircuit> i think the real issue is that there's no way to signal to peers that you want them to handle an addr message specially
 37 2015-04-07 00:40:46 <phantomcircuit> ideally you would send an addr message containing all of your local addresses with a special flag indicating that the peer should only forward them to peers which that peer itself had made an outbounc connection to
 38 2015-04-07 00:40:49 <phantomcircuit> outbound*
 39 2015-04-07 00:41:16 <phantomcircuit> actually something approximating that might be possible without p2p protocol modification
 40 2015-04-07 00:42:29 <phantomcircuit> if any of the addresses in an addr message are what you think the remote peer's address is treat it differently
 41 2015-04-07 00:43:04 <phantomcircuit> so an adversary is going to at best see which peers your peers are connected to
 42 2015-04-07 00:44:47 <andytoshi> hmmm
 43 2015-04-07 00:45:08 <andytoshi> that seems like the attacker should still be able to extract a lot of information
 44 2015-04-07 00:45:40 <andytoshi> maybe not
 45 2015-04-07 00:45:42 <andytoshi> well, not easily
 46 2015-04-07 00:48:24 <phantomcircuit> andytoshi, well and it relies on the other nodes cooperating which initially they certainly wont
 47 2015-04-07 00:49:04 <phantomcircuit> could add a new p2p message which older nodes would simply ignore and just fix the trickle logic
 48 2015-04-07 00:52:51 <andytoshi> by "fix the trickle logic" you mean infer your peers' addresses and treat them specially?
 49 2015-04-07 00:53:00 <andytoshi> does the new p2p message accomplish anything beyond that?
 50 2015-04-07 00:53:58 <phantomcircuit> andytoshi, no i mean actually change it such that it trickles addr messages
 51 2015-04-07 00:54:07 <phantomcircuit> it's currently doesn't do that
 52 2015-04-07 00:54:39 <phantomcircuit> i suspect fingerprinting using addr messages would work pretty well right now
 53 2015-04-07 00:54:42 <phantomcircuit> :/
 54 2015-04-07 00:54:49 <andytoshi> it's definitely an improvement
 55 2015-04-07 01:03:40 <phantomcircuit> andytoshi, yeah
 56 2015-04-07 01:03:44 <phantomcircuit> addr vAddr 1 x.x.x.x:8333
 57 2015-04-07 01:03:46 <phantomcircuit> facepalm
 58 2015-04-07 01:33:31 <phantomcircuit> <isis> [resent because i can't speak in #bitcoin-dev] phantomcircuit: andytoshi: Is the idea to change getaddr/getpeeraddr to preferentially return .onion peers/addresses when speaking to a .onion node, and to return IP addresses when speaking to a non-Tor node?
 59 2015-04-07 01:33:55 <phantomcircuit> the goal is to prevent an attacker from detecting which peers you are connected to
 60 2015-04-07 01:34:31 <phantomcircuit> preferentially publishing tor/non-tor like that would probably be a bad idea
 61 2015-04-07 01:34:54 <phantomcircuit> but preferentially publishing your local address to tor hidden services might help accomplish the goal of preventing fingerprinting
 62 2015-04-07 01:45:20 <petertodd> wumpus: FWIW the unit tests already depend on LGPL code; python-bitcoinrpc is LGPL, not MIT
 63 2015-04-07 01:45:29 <petertodd> sdaftuar: ^
 64 2015-04-07 01:46:56 <petertodd> wumpus: specifically, see the license in qa/rpc-tests/python-bitcoinrpc/bitcoinrpc/authproxy.py
 65 2015-04-07 01:48:07 <phantomcircuit> petertodd, plz2argue about addr/getaddr
 66 2015-04-07 01:48:54 <petertodd> phantomcircuit: ?
 67 2015-04-07 01:49:59 <phantomcircuit> petertodd, the addr trickling logic needs to be reworked
 68 2015-04-07 01:50:06 <phantomcircuit> <phantomcircuit> the goal is to prevent an attacker from identifying which nodes are connected
 69 2015-04-07 01:50:14 <phantomcircuit> strategies?
 70 2015-04-07 01:50:42 <petertodd> phantomcircuit: ah, yeah, I haven't followed that conversation at all
 71 2015-04-07 01:56:55 <andytoshi> petertodd: fwiw in the above i was basically being a sounding board ... there shouldn't be anything hard to read
 72 2015-04-07 02:13:45 <phantomcircuit> so getaddr doesn't work for outbound connections to prevent this fingerprinting attack http://arxiv.org/pdf/1410.6079.pdf
 73 2015-04-07 02:13:53 <phantomcircuit> which trivially linked tor/non tor
 74 2015-04-07 02:26:40 <phantomcircuit> im thinking that isn't the right solution
 75 2015-04-07 02:28:24 <jgarzik> bitcoind HEAD crash w/ no core file.  crappy cloudatcost server or bitcoind bug?
 76 2015-04-07 02:28:29 <jgarzik> 
ACTION bets on the former

 77 2015-04-07 05:22:07 <blackmatrix_ny> I get this error when I start my cpuminer. My bitcoind is running in regtest mode. The error is HTTP request failed: The requested URL returned error: 500 Internal Server Error
 78 2015-04-07 05:22:14 <blackmatrix_ny> Anybody come across this ?
 79 2015-04-07 05:35:21 <wumpus> petertodd: I didn't know. that's an argument to reduce the amount of LGPL code, not increase it
 80 2015-04-07 05:35:23 <Luke-Jr> blackmatrix_ny: it's not going to work. didn't I already answer you in -mining?
 81 2015-04-07 05:37:54 <wumpus> Luke-Jr: did you know we had LGPL code in the repository?
 82 2015-04-07 05:38:39 <wumpus> strange that it never came up, although it's not that big of a deal as it's only in test code
 83 2015-04-07 05:41:57 <Luke-Jr> wumpus: I knew we had non-MIT *graphics*, but I wasn't aware of the rpc-tests thing
 84 2015-04-07 05:42:15 <Luke-Jr> I don't think LGPL is unreasonable for unit test dependencies
 85 2015-04-07 05:42:28 <Luke-Jr> and of course I think it's a bad idea to copy dependencies into the tree, especially when unnecessary <.<
 86 2015-04-07 05:42:41 <wumpus> for external dependencies, ok, but in this case t is part of the repository
 87 2015-04-07 05:42:55 <Luke-Jr> there's no reason this shouldn't be external IMO
 88 2015-04-07 05:43:04 <wumpus> the tests need to be self-contained
 89 2015-04-07 05:43:33 <Luke-Jr> Why?
 90 2015-04-07 05:43:42 <Luke-Jr> they don't include a bundled copy of Python either..
 91 2015-04-07 05:43:47 <wumpus> because that makes sure as many peole as possible can execute them
 92 2015-04-07 05:44:19 <wumpus> python comes pretty much by standard with every linux distro
 93 2015-04-07 05:44:37 <wumpus> the bitcoin specific libraries are usually not even available as package
 94 2015-04-07 05:45:10 <wumpus> in any case I agree that an external LGPL dependency would not be a problem, but an internal one is
 95 2015-04-07 05:46:06 <Luke-Jr> there's no reason we couldn't have a script that downloaded and put bitcoinrpc in the right location
 96 2015-04-07 05:46:11 <Luke-Jr> in fact, git has one builtin..
 97 2015-04-07 05:46:41 <wumpus> bitcoinrpc is a trivial dependency
 98 2015-04-07 05:47:07 <wumpus> python-bitcoinlib would not be, of course.
 99 2015-04-07 05:48:14 <wumpus> in any case sdaftuar only needs a few routines, if he can find them under MIT that'd be preferable
100 2015-04-07 05:49:39 <Luke-Jr> 
ACTION notes BFGMiner has 4 external dependencies distributed as git submodules, and users do just fine (as long as the dependency project remains online)

101 2015-04-07 07:06:34 <petertodd> wumpus: legally speaking, what's the issue with LGPL? the only case where the license requirements kick in is if someone wants to distribute binaries w/o source... but it's python code, practically no-one goes to the trouble of compiling it then distributing it w/o source
102 2015-04-07 07:07:10 <petertodd> wumpus: equally, if they're doing that why do they care about the unit tests being distributed?
103 2015-04-07 07:07:44 <wumpus> petertodd: the point is just clarity; the more exceptions to MIT are in the repository, the more tedious it is to document that. I thought the only exceptions were the UI icons.
104 2015-04-07 07:08:09 <petertodd> wumpus: what's there to document? the files themselves are perfectly well documented
105 2015-04-07 07:08:16 <wumpus> right now we have a COPYING file in the root that lists the MIT license, strictly this is invalid already.
106 2015-04-07 07:08:49 <wumpus> I don't feel like having an argument about this, if no one but me cares I'm fine with more LGPL files, bring them on
107 2015-04-07 07:09:25 <petertodd> wumpus: well, you can count me in as not caring :)
108 2015-04-07 07:09:48 <wumpus> I wouldn't doubt that
109 2015-04-07 07:11:24 <lewellyn> wumpus: though my opinion bears little weight, i'm behind you on this.
110 2015-04-07 07:13:19 <wumpus> lewellyn: at least it's safest until someone can ask a lawyer that specialized in this, wouldn't want anyone claiming that suddenly the entire repository needs to be LGPL, it's not like there isn't enough drama yet
111 2015-04-07 07:13:40 <phantomcircuit> multiple licenses could cause issues
112 2015-04-07 07:13:47 <phantomcircuit> i wasn't aware of the ui icons for example
113 2015-04-07 07:13:50 <lewellyn> yeah. and that's a lot of the problem with the gnu licenses. they're designed to do that. :(
114 2015-04-07 07:14:14 <wumpus> phantomcircuit: that's been always the case and well documented, see assets-attribution
115 2015-04-07 07:14:23 <wumpus> lewellyn: right
116 2015-04-07 07:14:43 <phantomcircuit> wumpus, sure but why would i ever read that?
117 2015-04-07 07:14:53 <lewellyn> it's less problematic for art assets as they're obviously discrete units.
118 2015-04-07 07:14:55 <phantomcircuit> COPYING is a straight MIT license
119 2015-04-07 07:15:05 <wumpus> phantomcircuit: yes, why.
120 2015-04-07 07:15:17 <wumpus> WHY
121 2015-04-07 07:15:37 <lewellyn> echo "Don't." > COPYING # :)
122 2015-04-07 07:15:39 <phantomcircuit> wat
123 2015-04-07 07:15:48 <wumpus> it could cost three minutes of your time to look at it
124 2015-04-07 07:16:01 <wumpus> lewellyn: hehe
125 2015-04-07 07:16:15 <lewellyn> wumpus: "attribution" doesn't imply "different license", though.
126 2015-04-07 07:16:18 <phantomcircuit> wumpus, no i mean if i was trying to identify the license for the code
127 2015-04-07 07:16:28 <phantomcircuit> why would anybody go past the COPYING or LICENSE file?
128 2015-04-07 07:16:35 <wumpus> lewellyn: well MIT license doesn't need attribution
129 2015-04-07 07:16:43 <wumpus> lewellyn: a lot of the graphics licenses do
130 2015-04-07 07:16:58 <lewellyn> *need*, no. but it's a nice thing to do for assets which make metadata difficult to deal with.
131 2015-04-07 07:17:28 <phantomcircuit> wumpus, there's potentially a problem there for whoever did the commit with those icons in it..
132 2015-04-07 07:17:31 <wumpus> in practice it's impossible to find good icons under MIT license, but again you're welcome to try, this discussion has been going on since 2008 or so and it's not goinga nywhere
133 2015-04-07 07:17:45 <wumpus> phantomcircuit: I'm so scared now
134 2015-04-07 07:17:57 <phantomcircuit> wumpus, har har
135 2015-04-07 07:18:01 <lewellyn> wumpus: the key is to find someone who will do new icons on commission for you to use however.
136 2015-04-07 07:18:35 <wumpus> lewellyn: now you're funny
137 2015-04-07 07:18:53 <lewellyn> i bet i could find someone who would be willing to do a new set for little-to-no cost
138 2015-04-07 07:19:02 <wumpus> commission, hah, as if anyone would pay for that
139 2015-04-07 07:19:14 <phantomcircuit> wumpus, no you mean
140 2015-04-07 07:19:20 <phantomcircuit> "feel free to pay for that"
141 2015-04-07 07:19:36 <lewellyn> wumpus: someone just told me "ok" when i suggested she do it.
142 2015-04-07 07:20:02 <lewellyn> so if the license is problematic, it's definitely possible to just replace them.
143 2015-04-07 07:20:17 <wumpus> jonasschnelli already re-did a lot of them
144 2015-04-07 07:20:20 <wumpus> there's a few with License: CC BY-SA left
145 2015-04-07 07:20:27 <wumpus> in any case, feel free to solve this problem, I will not argue about it further
146 2015-04-07 07:20:44 <lewellyn> no one's arguing with you.
147 2015-04-07 07:20:59 <lewellyn> phantomcircuit and i are in agreement.
148 2015-04-07 07:21:38 <wumpus> well, implying that the person that committed it has a problem is kind of... nasty
149 2015-04-07 07:21:51 <lewellyn> i can't speak for phantomcircuit on that comment.
150 2015-04-07 07:22:22 <lewellyn> but as for the tests, they're problematic. something needs to be done about them. but if the tests become the only lgpl bits, that should be an easier battle.
151 2015-04-07 07:22:22 <phantomcircuit> wumpus, it wasn't meant to be
152 2015-04-07 07:23:17 <phantomcircuit> that it could be an issue for them is clear though since the project as a whole is nominally MIT licensed
153 2015-04-07 07:23:42 <phantomcircuit> anybody found to be infringing on an LGPL or CC BY-SA could easily claim indemnity from the committer
154 2015-04-07 07:23:47 <phantomcircuit> which *is* nasty
155 2015-04-07 07:23:48 <wumpus> it's easy to replace the icons though, much easier than the code.
156 2015-04-07 07:23:59 <lewellyn> i'll pass on the info about where to find the current lgpl assets and hopefully she'll stop in tomorrow and poke you to work out any administrivia and logistics.
157 2015-04-07 07:24:01 <wumpus> in any case: Typicons made the CC-BY-SA icons, someone could contact them
158 2015-04-07 07:24:09 <wumpus> there are no LGPL assets
159 2015-04-07 07:24:19 <wumpus> just MIT and CC-BY-SA
160 2015-04-07 07:24:39 <lewellyn> oh. ok. so the tests ARE the only lgpl? then yeah. someone needs to figure out what to do about that
161 2015-04-07 07:24:43 <wumpus> yes
162 2015-04-07 07:24:52 <lewellyn> cc-by-sa isn't AS bad.
163 2015-04-07 07:27:12 <phantomcircuit> wumpus, i'd suggest adding any attribution stuff to the COPYING file
164 2015-04-07 07:27:23 <wumpus> you can do it yourself, you dont have to suggest it to me
165 2015-04-07 07:28:08 <lewellyn> i'd suggest keeping everything under one license ;)
166 2015-04-07 07:28:13 <lewellyn> wumpus: where is assets-attribution?
167 2015-04-07 07:28:44 <wumpus> doc, where else.
168 2015-04-07 07:28:46 <lewellyn> i'm trying to plop this all in an email to her.
169 2015-04-07 07:28:54 <lewellyn> alongside the license? :P
170 2015-04-07 07:30:00 <wumpus> be  sure to use the one in master, not 0.10, a lot changed sine
171 2015-04-07 07:30:19 <lewellyn> yeah. i'm linking her master.
172 2015-04-07 07:32:27 <fanquake> ;;blocks
173 2015-04-07 07:32:28 <gribble> 351087
174 2015-04-07 07:34:14 <lewellyn> wumpus: ok. i sent her everything she might need to know. maybe the icons can be all MIT soon. :)
175 2015-04-07 07:34:31 <wumpus> lewellyn: thanks!
176 2015-04-07 07:35:11 <lewellyn> it's a roundabout way of putting pressure on the tests, i realize. but it's also probably the least drama-ridden. once they're the elephant in the room without any way to deflect attention, hopefully something can happen there.
177 2015-04-07 07:35:47 <lewellyn> i don't know what the right answer is. but i know that inaction is definitely not it. :P
178 2015-04-07 07:39:01 <wumpus> well, removing the tests would be worse than removing the icons
179 2015-04-07 07:39:47 <wumpus> I certainly wouldn't go along with that. I'm just against adding more LGPL code.
180 2015-04-07 07:40:00 <lewellyn> yes. and rewriting them isn't trivial.
181 2015-04-07 07:40:15 <lewellyn> indeed. but if no lgpl code exists, it makes adding more indefensible :D
182 2015-04-07 07:40:37 <wumpus> you wouldn't need to rewrite the tests, just the rpc proxy with something that provides the same interface
183 2015-04-07 07:41:19 <lewellyn> hm.
184 2015-04-07 07:41:23 <wumpus> it'd be quite a straightforward use of httplib and json modules
185 2015-04-07 07:41:51 <wumpus> I don't have time for it, but if anyone feels like giving a student a project or such.... :p
186 2015-04-07 07:41:59 <lewellyn> i'm allergic to taking on new projects right now, since i'm still settling into new employment and don't want to promise things i can't necessarily finish :(
187 2015-04-07 07:43:09 <lewellyn> also, i'm not entirely sure about how contributing to open source works with my current employer. in the past, i've red-lined documents to make sure i can do so unfettered but i haven't seen the proper documents to do that to yet.
188 2015-04-07 07:51:37 <Luke-Jr> wumpus: huh? we have LGPL icons..
189 2015-04-07 07:51:45 <Luke-Jr> lewellyn: CC-BY-SA is far worse than LGPL
190 2015-04-07 07:52:03 <Luke-Jr> (it's non-free)
191 2015-04-07 07:52:14 <lewellyn> it's a different kind of bad, yes.
192 2015-04-07 07:53:07 <lewellyn> Luke-Jr: which are lgpl? assets-attribution doesn't list any.
193 2015-04-07 07:53:44 <Luke-Jr> ugh, jonasschnelli what are you doing. you can't relicense CC-BY-SA under MIT!
194 2015-04-07 07:53:49 <Luke-Jr> lewellyn: 0.10 branch
195 2015-04-07 07:54:31 <lewellyn> Luke-Jr: oh. so i should have her do both 0.10 and master's icons? and should i have her just redo them all, rather than just the ones listed as cc?
196 2015-04-07 07:56:08 <Luke-Jr> lewellyn: I don't consider LGPL to be a serious problem for icons, so 0.10 is okay by me (but maybe wumpus would like new ones for it?)
197 2015-04-07 07:56:49 <Luke-Jr> lewellyn: as for the second question, my comment was based on the assets-attribution.md comment that the "MIT" icons were based on CC-BY-SA ones
198 2015-04-07 07:56:59 <lewellyn> likewise, lgpl isn't serious for icons to me either. 00:14  lewellyn: it's less problematic for art assets as they're obviously discrete units.
199 2015-04-07 07:57:40 <lewellyn> Luke-Jr: yes, that's why i asked if i should just tell her to redo them all, since it doesn't say WHICH are based on the CC-BY-SA ones
200 2015-04-07 07:57:57 <Luke-Jr> true, ok
201 2015-04-07 07:58:10 <Luke-Jr> we could always ask jonasschnelli though :P
202 2015-04-07 07:58:52 <lewellyn> well, they're likely to be consistent if it's all one person's work.
203 2015-04-07 08:05:26 <wumpus> Luke-Jr: LGPL icons are already solved in master, it won't be' solved' in 0.10
204 2015-04-07 08:08:05 <Luke-Jr> wumpus: sgtm
205 2015-04-07 08:22:56 <wumpus> Luke-Jr: eh you're implying the MIT icons are derived from CC-BY-SA ones? or just 'based on' as in look vaguely alike?
206 2015-04-07 08:23:11 <Luke-Jr> * Some icons are based on Stephan Hutchings Typicons (these are under CC BY-SA license)
207 2015-04-07 08:23:12 <Luke-Jr> * License: MIT
208 2015-04-07 08:23:22 <wumpus> the second is not an issue, the first is not really possible
209 2015-04-07 08:23:58 <Luke-Jr> I would expect copyright law to consider "drawn to look like" as derived
210 2015-04-07 08:24:07 <wumpus> no
211 2015-04-07 08:25:06 <Luke-Jr> well, as long as someone is sure that "based on" is not derived, ok
212 2015-04-07 08:25:43 <wumpus> well obviously it depends on how close the match is, of course, but drawing other icons in a similar style (especially as it's already pretty generic in the pirst place) is certainly not a copyright violation
213 2015-04-07 08:26:19 <wumpus> e.g. you cannot copyright 'rounded single-color vector icons'
214 2015-04-07 08:26:30 <Luke-Jr> right
215 2015-04-07 08:27:36 <Luke-Jr> but that case has no need for a comment at all ;)
216 2015-04-07 08:27:49 <wumpus> yes, it merits some explanation in this case
217 2015-04-07 08:28:36 <wumpus> and indeed might be better to not mention it at all in that case
218 2015-04-07 08:29:49 <wumpus> or use another wording like 'inspired by'
219 2015-04-07 08:30:51 <Luke-Jr> +1
220 2015-04-07 08:46:44 <gmaxwell> (that is and should just be a quiet here except in emergency)
221 2015-04-07 10:18:59 <jonasschnelli> +1 for inspired by. But I think I did some icons by reassembling elements.
222 2015-04-07 10:19:40 <jonasschnelli> I'll check it and I might need to change the license to CC BY SA
223 2015-04-07 10:20:05 <jonasschnelli> (for the ones I'll reassembled)
224 2015-04-07 10:20:26 <jonasschnelli> Some I did from the scratch like the pickaxe.
225 2015-04-07 10:22:26 <Luke-Jr> jonasschnelli: CC-BY-SA is not an acceptable license, so if those exist, please inform us so they can be replaced before 0.11
226 2015-04-07 10:25:03 <jonasschnelli> Luke-Jr: just double checked the license: https://github.com/stephenhutchings/typicons.font its indeed CC BY SA. Where do you see the conflict with this license?
227 2015-04-07 10:25:32 <Luke-Jr> jonasschnelli: it's not a problem of conflict, it's a problem of unacceptable terms. CC-BY-SA is not a free license
228 2015-04-07 10:26:52 <jonasschnelli> I'm not a lawyer but I read http://creativecommons.org/licenses/by-sa/3.0/ and was thinking by mention the author and the link in the assets file would be enough.
229 2015-04-07 10:26:55 <Luke-Jr> hm, I may be thinking of just plain CC-BY or an older version actually. but aside from that, wumpus wants everything in git to be MIT licensed
230 2015-04-07 10:27:26 <Luke-Jr> jonasschnelli: just because it is legal, does not make it suitable for the project
231 2015-04-07 10:27:27 <wumpus> jonasschnelli: I think so too - replacing them is not *that* urgent, though having MIT licensed icons would be even better
232 2015-04-07 10:27:42 <jonasschnelli> Agreed. MIT would be much better.
233 2015-04-07 10:28:18 <jonasschnelli> I might do a re-creating soon because I'm not 100% happy with the icons.
234 2015-04-07 10:28:21 <wumpus> jonasschnelli: as I've said before I don't care that much about the license of the icons (as long as  it's legal of course). This just came up because of the license of some test-related code. For code it's more serious IMO.
235 2015-04-07 10:29:27 <wumpus> I mean for the icons it's trivial: if we wanted to be puritanical about it, we could put them in an optional seperate CC-BY-SA repository
236 2015-04-07 10:29:35 <wumpus> the standard client having no icons
237 2015-04-07 10:29:40 <jonasschnelli> Okay. Then I will keep the recreation of the icons on my list (but not at high priority)
238 2015-04-07 10:29:48 <wumpus> but I'm not that worried.
239 2015-04-07 10:29:51 <gmaxwell> well it's not urgent, just something to work towards improving.
240 2015-04-07 10:30:23 <Luke-Jr> found it: CC-BY-SA-3.0 section 4(d) makes it non-free
241 2015-04-07 10:30:57 <gmaxwell> Luke-Jr: worry first about the openssl license.
242 2015-04-07 10:31:34 <Luke-Jr> gmaxwell: OpenSSL license is free
243 2015-04-07 10:31:41 <Luke-Jr> just requires excessive attribution
244 2015-04-07 10:31:43 <wumpus> is openssl GPL or LGPL?
245 2015-04-07 10:31:51 <Luke-Jr> wumpus: old MIT
246 2015-04-07 10:32:04 <wumpus> 'old MIT' doesn't sound too bad?
247 2015-04-07 10:32:09 <gmaxwell> Luke-Jr: openssl license requires every marketing material about your product have an add for openssl. IIRC.
248 2015-04-07 10:32:12 <Luke-Jr> wumpus: it's GPL-incompatible at least
249 2015-04-07 10:32:39 <gmaxwell> it's not even just the advertising clause MIT, its their own screwy version of it.
250 2015-04-07 10:32:45 <Luke-Jr> gmaxwell: right. CC-BY-SA-3.0 requires your derived works to preserve the Original Author's reputation/honor
251 2015-04-07 10:32:45 <wumpus> luckily we haven't included any openssl code in the repository
252 2015-04-07 10:33:12 <gmaxwell> I'd almost swear that it's so that customs knows which products contain the backdoored crypto that its fine to iran. :P
253 2015-04-07 10:33:29 <wumpus> hehehe :P
254 2015-04-07 10:33:40 <gmaxwell> Luke-Jr: openssl 3/4 are kind of contradictory too.
255 2015-04-07 10:34:37 <gmaxwell> I suppose we're flagrantly in violation of the openssl license, depending on if "advertising materials" describes anything we've ever done to promote bitcoin core. :)
256 2015-04-07 10:34:59 <wumpus> in any case, luckily we have a migration path from openssl
257 2015-04-07 10:35:20 <gmaxwell> maybe we should add that to the splash "This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/); though we regret it and we're moving away from it as fast as we can!"
258 2015-04-07 10:35:24 <gmaxwell> :)
259 2015-04-07 10:35:43 <gmaxwell> sure sure.
260 2015-04-07 10:35:52 <wumpus> bitcoind --version shows "This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit <https://www.openssl.org/> and cryptographic software written by Eric Young and UPnP software written by Thomas Bernard."
261 2015-04-07 10:36:11 <gmaxwell> didn't mean to worm can open; just trying to mix in some fun perspective.
262 2015-04-07 10:36:33 <Luke-Jr> gmaxwell: the About dialog already says something like that too
263 2015-04-07 10:36:44 <gmaxwell> Luke-Jr: if you think the cc-by-sa images should be a higher priority, can you contact their original authors and try to get more liberal licenses? I doubt the authors care about the specifics at all.
264 2015-04-07 10:37:13 <wumpus> there's just one guy I think
265 2015-04-07 10:37:45 <wumpus> Designer: Stephen Hutchings (and more)  .. depending on who "and more" is :p but it's probably findable on that typicons site
266 2015-04-07 10:38:18 <gmaxwell> (if you do, please just ask if he could adopt an additional license in parallel to match our project; and say that we're concerned that the cc-by-sa-3.0 isn't consistent with the rest of our licensing)
267 2015-04-07 10:38:56 <Luke-Jr> omit the real issue?
268 2015-04-07 10:39:11 <wumpus> isn't that the real issue?
269 2015-04-07 10:39:26 <Luke-Jr> IMO the real issue is that the license terms are non-free
270 2015-04-07 10:39:47 <Luke-Jr> so by using the icons as-is, Mr. Hutchings has special privileges with regard to Bitcoin Core
271 2015-04-07 10:40:06 <gmaxwell> Luke-Jr: I'm suggesting not getting into a license details debate with someone who probably don't know or care about the details and would probably would accept whatever we ask if we don't ask in a way thats possibly insulting. ("This gift you gave isn't good enough!") :)
272 2015-04-07 10:40:09 <wumpus> you can always ask, I guess he won't relicense those icons for free but it doesn't necessarily have to cost a lot
273 2015-04-07 10:40:49 <Luke-Jr> 5 potential committers on his git repo
274 2015-04-07 10:41:43 <wumpus> then the question is, do they affect the icons we've used listed in assets-attribution
275 2015-04-07 10:41:54 <gmaxwell> (well I suppose you could say that specifically you're concerned that 4(d) isn't really in the spirit of free licensing. but in years of doing license requests for wikimedia commons I've always found saying less to work better; "hey we like your work, we'd be more comfortable with these other terms, is this okay?")
276 2015-04-07 10:41:57 <wumpus> we don't need the entire set just those.
277 2015-04-07 10:43:07 <wumpus> heh yes, artists don't really know much about licensening details in general, and I'm sure could be offended if their work is 'not free enough'
278 2015-04-07 10:46:05 <jonasschnelli> Hutchings probably don't care about the license. I think he did choose a license randomly among licenses he know (and are common for designer)
279 2015-04-07 10:46:08 <jonasschnelli> He is also
280 2015-04-07 10:47:18 <jonasschnelli> Licensing under SIL Font: http://scripts.sil.org/cms/scripts/page.php?item_id=OFL_web
281 2015-04-07 10:48:01 <jonasschnelli> But I think its not worth to go to deep here because i will redesign most of the icons and get rid of the CC By SA license soon.
282 2015-04-07 10:48:03 <Luke-Jr> http://0bin.net/paste/o2knSVxmoPbLRavk#xx17GR12+R9CMLuTHfFDB4EDHzGjHai27f2Ya3muopv look good?
283 2015-04-07 10:49:09 <jonasschnelli> Luke-Jr: I'm not sure if we should bother the author with this.
284 2015-04-07 10:49:15 <Luke-Jr> jonasschnelli: SIL isn't free either :p
285 2015-04-07 10:49:25 <wumpus> also provide a link to assets-attribution.md on github so he knows which icons are involved
286 2015-04-07 10:50:19 <jonasschnelli> Luke-Jr: the letter looks good IMO.
287 2015-04-07 10:51:29 <wumpus> maybe add something that we like the icons and would like to use them, but due to the license incompatibility may have to replace them
288 2015-04-07 10:51:41 <jonasschnelli> +1
289 2015-04-07 10:54:10 <Luke-Jr> http://0bin.net/paste/6YhYIhpEisAfq18Z#qwHPIL8WlztlK-qqaqpNyUJPqHtMHVPf3YuQX09alVx
290 2015-04-07 11:01:58 <wumpus> looks ok to me, but as said, I'd add something positive about the work as well 'A contributor to Bitcoin Core added...' is just an observation and not in itself very motivating to allow this.
291 2015-04-07 11:02:24 <wumpus> maybe it doesn't need to be, I don't know, I have no experience with this
292 2015-04-07 11:09:05 <Luke-Jr> hm, I sent it already but it just occurred to me that we're actually asking a pretty substantial change. BY-SA is more like GPL than MIT
293 2015-04-07 11:14:10 <wumpus> but asking him to for a GPL license would do us little good
294 2015-04-07 11:15:34 <Luke-Jr> right
295 2015-04-07 11:16:08 <Luke-Jr> maybe that bit about GPL compatibility issues will work more in our favour than I expected it to :p
296 2015-04-07 11:46:56 <morcos> wumpus: sorry if i'm just making more work for you.  what do you want me to do re: github contact?
297 2015-04-07 11:59:48 <wumpus> morcos: not sure; besides the few feature requests we've talked about, I don't really have that much to say there, I kind of had a shitty weekend and haven't thought about it much
298 2015-04-07 12:05:04 <morcos> sorry to hear..   well they seem to be wanting a phone call, which i agree is perhaps overkill, but maybe its best to do it to build a bit of a relationship.
299 2015-04-07 12:05:20 <morcos> i'm away from home this week, and can use that as an excuse to bump to next i fyou want
300 2015-04-07 12:07:04 <morcos> alternatively if you want to let it drop i can just shoot them a compilation of what we've come up with already
301 2015-04-07 12:07:56 <morcos> one thing i'd like to ask about, although it might be a stupid question is why you need to be an admin to add a webhook, i'd like to be able to do that for the bitcoin project to have our Slack get all activity
302 2015-04-07 12:09:30 <wumpus> we have a webhook set to post everything to #bitcoin-core-dev, maybe it could listen there
303 2015-04-07 12:18:36 <wumpus> if you would like it reported anywhere else I don't mind adding another hook; sure, would be useful if you could add notification hooks to other people's repositories nevetheless
304 2015-04-07 12:55:09 <hearn> jonasschnelli: i'm pondering a dedicated IRC channel for wallet developers. wdyt?
305 2015-04-07 12:57:31 <jonasschnelli> hearn: yes. I think its a good idea. Hopefully there will be some "traffic".
306 2015-04-07 12:58:56 <hearn> jonasschnelli: i will poll a few other devs and see what they think before creating one
307 2015-04-07 13:13:19 <blackmatrix_ny> Luke-Jr, Hi Luke, just seeing the message you sent yesterday after I went to bed...I will get back to you later as I'm running out for work now
308 2015-04-07 14:00:44 <wumpus> morcos: lol another thing we may want to mention to github, people getting confused about what a pull request is: https://github.com/bitcoin/bitcoin/pull/5980
309 2015-04-07 14:01:49 <wumpus> this is not just once, we've got many of those, the hypothesis is that some people think they need to open a pul lrequest to download the source
310 2015-04-07 15:20:28 <ajweiss> i've noticed that a number of nodes on testnet send a ping before they send a version message...  is this an old version?
311 2015-04-07 15:33:27 <wumpus> I don't know when, but yes I remember that was fixed at some point
312 2015-04-07 15:37:29 <wumpus> must be really old. Looking at the history of SendMessages, that "Don't send anything until we get their version message" code has been there forever.
313 2015-04-07 15:45:19 <wumpus> so it's more likely to be another implementation doing that
314 2015-04-07 18:27:41 <gmaxwell> petertodd: someone asked me about CLTV last night and I said "ask petertodd"
315 2015-04-07 18:32:20 <lewellyn> wumpus: Luke-Jr: jonasschnelli: romonster is here; she's the one i poked last night/this morning (depending on your local timezone) about assisting with icons, if you all would like more UI people involved... especially one who's more aware of open source licenses than some of the potential choices in the world :)
316 2015-04-07 18:33:43 <jonasschnelli> romonster, lewellyn: nice. So you say romonster is willing to contribute icons?
317 2015-04-07 18:34:31 <jonasschnelli> romonster, any link to some icons you did?
318 2015-04-07 18:34:36 <romonster> i am, but i do need to see the existing icons in use so i can get an idea of how they are being used
319 2015-04-07 18:35:56 <romonster> http://www.roseviolet.net/buttons-icons.html
320 2015-04-07 18:36:02 <jonasschnelli> romonster, okay. Nice! I can provide you some screenshots.
321 2015-04-07 18:36:12 <jonasschnelli> You can also start here: https://github.com/bitcoin/bitcoin/pull/5219
322 2015-04-07 18:37:21 <jonasschnelli> romonster, i have to leave but try to register on github and pm me if you need screenshots.
323 2015-04-07 18:37:37 <romonster> I will
324 2015-04-07 18:37:46 <sipa> phantomcircuit: i saw some discussion about addrman getaddr
325 2015-04-07 18:43:07 <lewellyn> jonasschnelli: good job. i've been trying to get her to register on github for years. ;)
326 2015-04-07 18:43:20 <lewellyn> i have an organization to transfer to her ;)
327 2015-04-07 18:44:07 <romonster> lewellun: You might have to help me with that tonight
328 2015-04-07 18:44:13 <romonster> aargh
329 2015-04-07 18:48:55 <lewellyn> 
ACTION wonders how romonster managed to not tab complete :D

330 2015-04-07 18:49:43 <romonster> Because I typed your name after the fact, so tab completion doesn't work
331 2015-04-07 18:50:02 <lewellyn> :)
332 2015-04-07 18:58:20 <maraoz> question about the protocol: are responses to `getblocks` messages guaranteed to be ordered by height? (I assume the logic answer is yes, but it's not explicitly stated in the docs)
333 2015-04-07 19:03:07 <sipa> maraoz: every implementation i know of does so
334 2015-04-07 19:05:53 <chris13243> lets say you have a bitcoin address with $1000 worth of bitcoin on it, but that btc came from a bunch of tiny $0.05 btc inputs. is there an easy way to bunch all those tiny inputs into one giant input without spending a ton in tx fees?
335 2015-04-07 19:06:34 <sipa> chris13243: whether all those inputs belong to the same address or not is totally irrelevant
336 2015-04-07 19:06:54 <sipa> you're combining many inputs into one, and that requires a large transaction - with all its associated costs
337 2015-04-07 19:12:32 <phillipsjk> Though such a large transaction will be smaller than a bunch of smaller transactions
338 2015-04-07 19:13:40 <chris13243> so its dafe to say it costs more to spend bitcoin gotten from microtransactions than it is to spend bitcoin given to you in one output?
339 2015-04-07 19:13:41 <gmaxwell> the bitcoin system has no real concept of addresses, it tracks coins.
340 2015-04-07 19:13:47 <gmaxwell> chris13243: correct.
341 2015-04-07 19:14:10 <chris13243> is there a potential protocol change to address this?
342 2015-04-07 19:14:26 <sipa> chris13243: no, that would be terrible for privacy
343 2015-04-07 19:14:36 <sipa> chris13243: you don't want to encourage people to reuse address
344 2015-04-07 19:14:54 <sipa> and even if we wanted to, it would be a massive change
345 2015-04-07 19:15:31 <Apocalyptic> you don't want to encourage microtransactions as well
346 2015-04-07 19:16:12 <chris13243> why? microtransactions is one of bitcoins killer features
347 2015-04-07 19:16:14 <phillipsjk> would combining many inputs into one large output be enough to bump the transaction priority?
348 2015-04-07 19:16:49 <sipa> chris13243: it's a killer feature for bitcoin-the-currency, not for bitcoin-the-base-blockchain-technology-layer
349 2015-04-07 19:17:05 <phillipsjk> chris13243, Bitcoin is not suited for microtransactions. All transactions are broadcast world-wide and stored essentially forever.
350 2015-04-07 19:17:17 <sipa> note that everyone in the world needs to be able to verify your transactions if they want to; they cost/benefits just don't weigh up
351 2015-04-07 19:21:20 <chris13243> bitcoin makes it super easy to take a large amount of money and plit it u into a bunch of smaller parts, but it is very hard to take small amounts and combine them into a large amount transaction
352 2015-04-07 19:21:31 <chris13243> if bitcoin coul do that it would be perfect for microtransactions
353 2015-04-07 19:21:53 <sipa> chris13243: that's not correct
354 2015-04-07 19:22:03 <sipa> splitting is also expensive
355 2015-04-07 19:23:08 <chris13243> one input worth 5 cents going out to 5 different addresses, is one tx and not a very big one at that. 1 cent transaction fee and that tx will confirm with no delay
356 2015-04-07 19:23:42 <sipa> inputs are around 3-4 times large than outputs
357 2015-04-07 19:24:01 <sipa> splitting to 100 outputs will be around as expensive as combining from 25 inputs
358 2015-04-07 19:24:07 <sipa> there is some assymmetry but not much
359 2015-04-07 19:24:21 <sipa> anyway, you're arguing about what the technology should do
360 2015-04-07 19:24:31 <sipa> come up with a design on how to accomplish it cheaply
361 2015-04-07 19:25:02 <sipa> it's possible, but it will be very different system from bitcoin, with very different privacy/scalability/security tradeoffs
362 2015-04-07 19:25:33 <chris13243> you can do that now
363 2015-04-07 19:25:39 <chris13243> check out autotip
364 2015-04-07 19:26:04 <chris13243> it uses one cent tx fee and you can have multile outputs and the txc onfirms quickly
365 2015-04-07 19:26:36 <sipa> the network by design only allows a limited amount of low-fee transactions
366 2015-04-07 19:26:41 <Crowley2k> i'm assuming we're not talking about bitcoin here,right?
367 2015-04-07 19:26:52 <chris13243> yes bitcoin
368 2015-04-07 19:27:13 <sipa> chris13243: ultimately, bitcoin transactions have a cost per byte
369 2015-04-07 19:27:32 <sipa> a limited number of transactions are allowed to bypass that, pretty much for publicity purposes
370 2015-04-07 19:27:55 <chris13243> yes i agree
371 2015-04-07 19:28:06 <sipa> but if you're not paying the fee, someone else is (in bandwidth cost, storage costs, processing costs, ...)
372 2015-04-07 19:28:56 <sipa> and of course, it were nice if bitcoin were usable for more purposes, with low costs, at infinite scalability, with perfect security, and everyone would be rich, ...
373 2015-04-07 19:29:08 <sipa> but the reality of the technology and economics constrain us
374 2015-04-07 19:31:05 <Crowley2k> well..the 'economics' has to play its part for the currency to have a value
375 2015-04-07 19:37:46 <maraoz> sipa: thanks
376 2015-04-07 20:01:19 <morcos> sipa: it seems like the code that processes orphan transactions doesn't work correctly if an orphan tx had inputs missing from 2 separate tx's
377 2015-04-07 20:02:10 <morcos> the orphan will be erased when the first tx containing a missing input comes in
378 2015-04-07 20:02:13 <sipa> morcos: heh...
379 2015-04-07 20:02:50 <morcos> whats the reason that the tx we're processing is added to vEraseQueue in the first place, just belt and suspenders
380 2015-04-07 20:03:28 <sipa> perhaps i never really looked at that code
381 2015-04-07 20:03:51 <morcos> heh, sorry, i sometimes just default to assuming you wrote it all..  :)
382 2015-04-07 20:03:56 <sipa> lol
383 2015-04-07 20:04:18 <morcos> ok i'll put it on my list to follow up on it
384 2015-04-07 20:27:16 <sbeta> Hi all, anyone here has some testnet coins to send me? mkVuZV2kVtMzddQabFDanFi6DTwWYtgiCn
385 2015-04-07 20:27:38 <sbeta> tnx in advance
386 2015-04-07 20:31:11 <sbeta> Colloquy crashed so not sure if my message went through or not, if anyone has some bitcoin testnet coins that could send over it will be really helpful, I’m developing a BIP32 multisig client and need to stress test the system on testnet, thanks in advance for the support :) mkVuZV2kVtMzddQabFDanFi6DTwWYtgiCn
387 2015-04-07 20:31:44 <sipa> sbeta: http://tpfaucet.appspot.com/
388 2015-04-07 20:32:47 <sbeta> sipa: thanks but I tried almost all of the faucets they give a small amount that is enough for a round of 20 transactions, this is way below the threashold I want to test.
389 2015-04-07 20:33:15 <sipa> ok; sorry, can't help you then
390 2015-04-07 20:39:33 <nkuttler> sbeta: you can send fractions of coins. or run the testnet box
391 2015-04-07 22:03:52 <sipa> sdaftuar: present?
392 2015-04-07 22:37:43 <cfields> jtimon: around?
393 2015-04-07 22:37:56 <jtimon> yep
394 2015-04-07 22:38:37 <cfields> jtimon: our checkpoints work is going to clash some, but only in a way that requires some fixups, nothing conceptual
395 2015-04-07 22:38:47 <jtimon> I'm in the middle of a refabase to separate tx from bheader/block things in my consensus branch
396 2015-04-07 22:38:48 <cfields> mind having a look and see if you agree with the premise? if so, i'll go ahead and PR
397 2015-04-07 22:39:08 <cfields> jtimon: https://github.com/theuni/bitcoin/tree/checkpoints-class
398 2015-04-07 22:41:00 <cfields> note that it adds Params() calls back into main that we'll want to get rid of.. it's really just bringing them up a level from before
399 2015-04-07 22:43:28 <jtimon> mhmm, at a first glance I don't think we will clash much, whatever you were changing in ContextualCheckBlockHeader, I'm moving to CheckIndexAgainstCheckpoint, doing the stuff for the index instead of the blockheader, it may even be a clean rebase on top of  #5975
400 2015-04-07 22:43:45 <jtimon> oh, Params(), yeah
401 2015-04-07 22:44:42 <jtimon> can you please append const CChainParams& params = Params(); at the beginning of your function and use params. instead of Params(). ?
402 2015-04-07 22:46:02 <jtimon> that will be cleaner for #5968 and #5598 to rebase on top of
403 2015-04-07 22:46:08 <cfields> ok
404 2015-04-07 22:46:51 <jtimon> beyond that, at a first glance the rebase of #5975 on top of your branch doesn't scare me
405 2015-04-07 22:47:12 <jtimon> and the other way around should be relatively simple too
406 2015-04-07 22:48:00 <cfields> great
407 2015-04-07 22:48:18 <cfields> thanks for having a look
408 2015-04-07 22:48:33 <jtimon> I mean, if you're creating a new function, use const CChainParams& params as a parameter rather than a variable declaration at the beginning, but try to avoid using Params() unless it is with a variable
409 2015-04-07 22:49:09 <phantomcircuit> gmaxwell, so what i've concluded is that the bulk address trickling logic should be replaced with a flag indicating that the next batch of addr messages should include the addresses in maplocaladdrs
410 2015-04-07 22:49:26 <jtimon> grep Params()\. should give less results each time, not more
411 2015-04-07 22:49:28 <phantomcircuit> which is cleared when it's triggered
412 2015-04-07 22:49:53 <phantomcircuit> that's the simplest thing i could think of which actually seems to work
413 2015-04-07 22:50:05 <phantomcircuit> and it nicely segments the selection of which node to use
414 2015-04-07 22:50:45 <cfields> jtimon: well like i said, it's not actually any more, it's just globals moved from checkpoints.o into main. so... made more obvious. Next step would be to parameterize em. I can go ahead and do that as part of this PR if you'd prefer?
415 2015-04-07 22:52:17 <jtimon> can you create the PR and mark with with WIP, PoC or something? it is easier to comment if I can see all the changes at once
416 2015-04-07 22:52:50 <jtimon> I mean, I can also fetch it but I think this will be faster
417 2015-04-07 22:53:48 <jtimon> well, don't worry, I'll fetch it
418 2015-04-07 22:54:11 <cfields> jtimon: I can go ahead and PR and just explain what needs to be done next. I'd prefer to avoid adding a bunch of WIP PR's, it makes it hard for reviewers to know what's current
419 2015-04-07 22:55:26 <jtimon> no worries, I'll smoke a cigarrete and fetch it
420 2015-04-07 22:56:16 <jtimon> one thing I want to check is if it's a clean reabase on top of #5975
421 2015-04-07 22:56:27 <cfields> heh ok
422 2015-04-07 22:56:37 <jtimon> jtimon/consensus_checkpoints
423 2015-04-07 22:56:50 <cfields> i'll add more detailed commit messages and re-push
424 2015-04-07 22:56:52 <cfields> looking
425 2015-04-07 22:59:16 <cfields> jtimon: clash. I think I can move things around to avoid that though
426 2015-04-07 23:01:38 <jtimon> back, should I wait to fetch then ?
427 2015-04-07 23:02:20 <jtimon> I mean, if you can rebase on top of that, I don't thinl we will class on checkpoints at all
428 2015-04-07 23:02:55 <jtimon> or class in ways that should be trivial for me to solve
429 2015-04-07 23:03:19 <cfields> ok. I'll just wait for that one to go in since it's much simpler, the rebase on top
430 2015-04-07 23:03:42 <jtimon> or you if my other changes related to verifyblockheader got merget first
431 2015-04-07 23:04:23 <jtimon> on the consensus subect, my plan is the following:
432 2015-04-07 23:06:02 <jtimon> 1) in addition to verifyScript, we want to expose at least verifyTx, verifyBlockHeader and verifyBlock, plus some partial checks for people to be able to put DoS or policy checks in between
433 2015-04-07 23:06:43 <jtimon> to verify blocks, you need to verify transactions AND verify blockheaders
434 2015-04-07 23:08:07 <jtimon> that means verifyBlock and its partial checks is the last tthing to do, thus verifyTransaction and verfiyBlockHeader can bbe done in parallel, whatever gets solved first can be exposed first
435 2015-04-07 23:10:49 <jtimon> 1) separate all its partial validations and adapt them to libconsensus requirements leaving only 1 "ugly dependency for each of them" [CBlockIndex in chain.o for verifyBlockHeeader and CCoinsViewCache in coins.o for verifyTx]
436 2015-04-07 23:10:49 <jtimon> for each of them, my goal is to:
437 2015-04-07 23:11:25 <jtimon> 2) one moveonly PR to txverify.cpp and blockverify.cpp respectively
438 2015-04-07 23:13:00 <jtimon> 3) At this point anybody can present proposals to replace CBlockIndex or CCoinsViewCache with interface that are suitable for the C API, my own ideas include function pointers and I have many doubts about them
439 2015-04-07 23:13:35 <cfields> mm, surely we can go simpler than CCoinsViewCache ?
440 2015-04-07 23:13:40 <jtimon> 4) move stuff in the makefile to expose whatever is ready without including any unused code in libconsensus
441 2015-04-07 23:14:29 <jtimon> yes, I mean, CCoinsViewEfficient was simpler than CCoinsViewCache, but it's not a final solution for a C API
442 2015-04-07 23:16:11 <jtimon> my point is that we can also parallelize the discussions on how to expose the utxo [while using CCoinsViewCache within bitcoin core] and the header index [while using CBlockIndex in bitcoin core] to libbitcoin
443 2015-04-07 23:17:12 <jtimon> while minimizing the discussions on meaningless things by having it all prepared to receive proposals on replacing JUST those 2 things, in parallel
444 2015-04-07 23:19:31 <cfields> ok, i agree on the premise i think. Sounds like you're wanting to free up the structures and functionality first so that the lib has all the functionality it would need, then worry about cleaning it up once it's untangled
445 2015-04-07 23:19:58 <jtimon> anyway, my next stop are a couple of PRs for step one in both tx and blockheader
446 2015-04-07 23:20:48 <jtimon> yes, but it is important to make sure there's only one "ugly dependency" for each case, so that we can focus on that one last
447 2015-04-07 23:21:13 <cfields> makes sense
448 2015-04-07 23:22:25 <jtimon> hopefully it will make more sense after I create some PRs I have in mind and improve the description for some others I have open
449 2015-04-07 23:23:54 <jtimon> I'm sorry I will have several WIP and PoC open PRs, but I can always "close them for now" once they have a link from the open ones
450 2015-04-07 23:25:35 <jtimon> btw nothing of this blocks the first step for the policy stuff, and all my Prs are mergeable right now with the exception of the 2 marked with WIP
451 2015-04-07 23:28:06 <cfields> nah, don't read anything into that. I was just pointing out that i have hard time keeping up with em. That probably says more about me :)
452 2015-04-07 23:30:50 <phantomcircuit> cs_vNodes is just for vNodes not the individual CNode entries in vNodes right?
453 2015-04-07 23:31:39 <phantomcircuit> i'd ask the original author but s_nakamoto
454 2015-04-07 23:32:07 <cfields> jtimon: going back to the checkpoints quickly, there's 1 change on your end that would make life easier for me.. Could you pass a CChainParams to CheckIndexAgainstCheckpoint rather than the hashGenesisBlock ?
455 2015-04-07 23:33:28 <jtimon> sure, I was passing that direcly because that's the only thing that needed from Consensus::Params, but you are putting new things in CChainParams, right?
456 2015-04-07 23:33:43 <phantomcircuit> specifically if i change a flag under the CNode object without acquiring the cs_vNodes lock am i going to be causing problems
457 2015-04-07 23:34:49 <cfields> jtimon: right, i'll need Params().Checkpoints() in there
458 2015-04-07 23:35:15 <jtimon> I will update #5975 with that tomorrow
459 2015-04-07 23:35:38 <cfields> great, thanks!
460 2015-04-07 23:35:48 <jtimon> but correction: you need params.Checkpoints(), not Params().Checkpoints() ;)
461 2015-04-07 23:36:15 <cfields> your params are Consensus::Params :p
462 2015-04-07 23:36:21 <phantomcircuit> im thinking i can do that
463 2015-04-07 23:37:10 <sdaftuar> sipa: present (for a little bit)
464 2015-04-07 23:37:16 <jtimon> somefunctions need CChainParams and others just Consensus::Params, but the variable/parameter is always params
465 2015-04-07 23:38:32 <cfields> jtimon: understood. I was just pointing out that you'll need to change the params in this case to CChainParams
466 2015-04-07 23:38:56 <jtimon> oh I see, the caller
467 2015-04-07 23:40:16 <jtimon> I believe the callers needed CChainParams already, but maybe not all of them, I will look into that thanks
468 2015-04-07 23:42:03 <cfields> yea, i think that may be the case as well. Might end up nuking a few more Params() as a side-effect
469 2015-04-07 23:46:03 <jtimon> nuking more Params(). will always make #5970 smaller so that's a cool side effect
470 2015-04-07 23:47:12 <jtimon> btw, do you still have that trivial branch? I wanted to suggest some include and makefile alphabetic sorts...
471 2015-04-07 23:49:07 <cfields> yep. There's a bunch of stuff piled up there, I'll be PR'ing it into master this week