1 2015-09-22 01:30:12 <CodeShark> hmm, is chainActive the structure in which to keep track of which softforks are active?
  2 2015-09-22 01:31:10 <CodeShark> and where should we persist this data?
  3 2015-09-22 01:31:36 <CodeShark> for versionbits, that is
  4 2015-09-22 01:33:27 <CodeShark> specifically, we need to persist the point where the softfork was activated and update it in the event of a reorg
  5 2015-09-22 01:34:04 <CodeShark> using the old version mechanism this isn't a problem - it can be done entirely statelessly with IsSuperMajority
  6 2015-09-22 01:38:48 <bedeho> is it correct that sighash used for p2sh does not copy in actual p2sh scriptPubKey into given scriptSig, but rather redeemscript?
  7 2015-09-22 01:41:09 <CodeShark> yes
  8 2015-09-22 01:48:01 <bedeho> CodeShark, ty
  9 2015-09-22 01:51:37 <bedeho> CodeShark, do signatures in mofn scriptSig need to preserve ordering of corresponding public keys in the scriptPubKey?
 10 2015-09-22 01:51:44 <CodeShark> yes
 11 2015-09-22 01:52:08 <CodeShark> to avoid O(n^2) complexity
 12 2015-09-22 02:12:41 <bedeho> CodeShark, ty
 13 2015-09-22 07:37:57 <diegoviola> hi
 14 2015-09-22 08:07:56 <diegoviola> jonasschnelli: ping?
 15 2015-09-22 08:08:10 <jonasschnelli> diegoviola: hi
 16 2015-09-22 08:08:47 <diegoviola> jonasschnelli: how do I open the pr on https://github.com/theuni/bitcoin
 17 2015-09-22 08:09:00 <jonasschnelli> diegoviola: https://github.com/theuni/bitcoin/pull/new/trivial-next
 18 2015-09-22 08:09:18 <jonasschnelli> maybe pull  https://github.com/theuni/bitcoin/ and rebase your PR on this branch
 19 2015-09-22 08:09:37 <jonasschnelli> git add remote theuni https://github.com/theuni/bitcoin
 20 2015-09-22 08:09:39 <jonasschnelli> git fetch --all
 21 2015-09-22 08:09:56 <jonasschnelli> git checkout -b localbranch
 22 2015-09-22 08:10:09 <jonasschnelli> git reset --hard theuni/trivial-next
 23 2015-09-22 08:10:24 <jonasschnelli> git cherry-pick 99ee4a656b1ca4bfeea8e0185c2344850cc84bfc
 24 2015-09-22 08:10:32 <jonasschnelli> git push origin
 25 2015-09-22 08:10:36 <jonasschnelli> :-)
 26 2015-09-22 08:11:15 <diegoviola> hrm
 27 2015-09-22 08:11:18 <jonasschnelli> thanks for opening your PR on theuni/bitcoin. We see hight load on bitcoin/bitcoin these days.
 28 2015-09-22 08:11:24 <jonasschnelli> s/height/heigh
 29 2015-09-22 08:12:08 <jonasschnelli> diegoviola: you could also use rebase.
 30 2015-09-22 08:14:17 <diegoviola> pull --rebase?
 31 2015-09-22 08:14:58 <diegoviola> git pull --rebase theuni master?
 32 2015-09-22 08:16:15 <jonasschnelli> diegoviola: maybe first git checkout -b theuni/trivial-next
 33 2015-09-22 08:16:46 <diegoviola> ok I'm on that branch, what now?
 34 2015-09-22 08:16:56 <jonasschnelli> git checkout master
 35 2015-09-22 08:17:05 <jonasschnelli> git rebase theuni/trivial-next
 36 2015-09-22 08:17:10 <jonasschnelli> or git rebase trivial-next
 37 2015-09-22 08:17:59 <diegoviola> fatal: Needed a single revision
 38 2015-09-22 08:18:01 <diegoviola> invalid upstream trivial-next
 39 2015-09-22 08:18:51 <jonasschnelli> maybe follow the cherry-pick approach above? Or check some git tutorials.
 40 2015-09-22 08:20:37 <wumpus> maybe the trivial-next branch is very much behind?
 41 2015-09-22 08:20:47 <wumpus> so that his changes don't apply?
 42 2015-09-22 08:20:49 <wumpus> dunno
 43 2015-09-22 08:21:19 <diegoviola> I did the pull --rebase, there are some conflicts now in my repo
 44 2015-09-22 08:21:42 <wumpus> diegoviola: I'd say don't bother for this time (unless it's for learning git better), next time, please take trivial changes there
 45 2015-09-22 08:21:48 <diegoviola> wumpus: ok
 46 2015-09-22 08:22:02 <diegoviola> wumpus: can I open the pull request and merge it? I'll use that other repo next time
 47 2015-09-22 08:22:06 <diegoviola> reopen*
 48 2015-09-22 08:22:08 <wumpus> yes
 49 2015-09-22 08:22:15 <diegoviola> thanks
 50 2015-09-22 08:22:38 <jonasschnelli> Yes. Makes sense.
 51 2015-09-22 08:22:55 <jonasschnelli> Sorry for the noise.
 52 2015-09-22 08:23:02 <diegoviola> np
 53 2015-09-22 08:25:37 <wumpus> np jonasschnelli, thanks for trying to explain git to people :)
 54 2015-09-22 08:25:46 <diegoviola> how do I fix the translations?
 55 2015-09-22 08:25:56 <jonasschnelli> diegoviola: register at transiflex.com
 56 2015-09-22 08:26:00 <diegoviola> already there
 57 2015-09-22 08:26:47 <diegoviola> https://www.transifex.com/user/profile/diegoviola/
 58 2015-09-22 08:30:32 <diegoviola> sorry for the ocd on this
 59 2015-09-22 08:49:31 <moa> http://pastebin.com/MSk3GGmt these warnings at link time are new
 60 2015-09-22 08:54:05 <wumpus> ipc_listener.cpp:(.text+0x63d): warning: the use of `tempnam' is dangerous, better use `mkstemp'
 61 2015-09-22 08:54:19 <wumpus> that's in zmq code, so file upstream issue please :)
 62 2015-09-22 08:55:01 <Arnavion> http://lists.zeromq.org/pipermail/zeromq-dev/2014-June/026408.html
 63 2015-09-22 08:57:40 <Arnavion> It seems to have been fixed last year as well
 64 2015-09-22 09:00:09 <moa> should have qualified that with it was depends build, but yes upstream issue (we are inheriting)
 65 2015-09-22 09:02:12 <diegoviola> ok translated on transifex as well
 66 2015-09-22 09:02:16 <diegoviola> fixed
 67 2015-09-22 09:02:20 <wumpus> depends package is 4.0.4, which is pretty old, maybe try to bump the release to 4.1.3
 68 2015-09-22 09:02:28 <diegoviola> do those locales get generated every day?
 69 2015-09-22 09:02:30 <wumpus> (which is latest stable according to zeromq.org)
 70 2015-09-22 09:03:04 <wumpus> diegoviola: before every rc/release, usually
 71 2015-09-22 09:03:20 <diegoviola> ok ty
 72 2015-09-22 09:03:35 <wumpus> (sometimes also periodically in between, but there's no set schedule)
 73 2015-09-22 09:13:30 <diegoviola> http://i.imgur.com/xpJXZ4R.png
 74 2015-09-22 09:13:44 <diegoviola> I want to edit these resource names to Qt but it doesn't allow me
 75 2015-09-22 09:13:48 <diegoviola> s/QT/Qt/
 76 2015-09-22 09:14:17 <diegoviola> Qt Translation 0.11.x and so on
 77 2015-09-22 09:14:48 <diegoviola> so it doesn't mislead anyone when translating
 78 2015-09-22 09:14:51 <diegoviola> further locales I mean
 79 2015-09-22 09:15:45 <diegoviola> the person who created those resources can probably edit it
 80 2015-09-22 09:20:00 <wumpus> I can change those I think...
 81 2015-09-22 09:20:35 <diegoviola> thanks
 82 2015-09-22 09:22:58 <diegoviola> I wish I wasn't this detail-oriented, but I can't help myself
 83 2015-09-22 09:27:25 <wumpus> updated
 84 2015-09-22 09:27:32 <diegoviola> thanks :D
 85 2015-09-22 09:29:52 <diegoviola> perfect
 86 2015-09-22 09:30:51 <diegoviola> is there any reason why I can't edit the locales for the 0.9.x files? or those don't matter anymore?
 87 2015-09-22 09:32:02 <diegoviola> it says I'm not allowed or something like that
 88 2015-09-22 09:33:25 <wumpus> it's to focus translator attention on 0.10/0.11 which are actively maintained
 89 2015-09-22 09:34:14 <diegoviola> ok
 90 2015-09-22 09:34:46 <wumpus> there's no point in changing 0.9 translations anymore - there's an oft chance there may be another minor release there in the case of e.g. a security problem, but most likely any effort there is wasted
 91 2015-09-22 09:35:27 <diegoviola> ok
 92 2015-09-22 09:36:21 <diegoviola> so I'm done I think, at least for now, thanks for your help
 93 2015-09-22 11:25:46 <jonasschnelli> any chance to get this merged? https://github.com/bitcoin/bitcoin/pull/6315
 94 2015-09-22 12:39:56 <jonasschnelli> hmm... is it true that during IBD, the nodes gets inv'ed/tx'ed by other nodes and the whole tx/inv traffic goes directly to trash/is useless?
 95 2015-09-22 12:47:50 <jonasschnelli> s/trash/nirvana
 96 2015-09-22 13:36:00 <morcos> Luke-Jr: or anyone that knows something about mining: sdaftuar and i are making another push on this mempool limiting stuff, and I'd like to get its interaction with prioritization (the mapDeltas kind) correct.
 97 2015-09-22 13:36:14 <morcos> unfortunately i don't really understand exactly how those are used in practice
 98 2015-09-22 13:36:28 <morcos> and for now the code is not very consistent.
 99 2015-09-22 13:37:21 <morcos> should transactions that have a delta applied to them just behave exactly as if that delta was their actual fee?  so they can still be evicted etc. if that modified fee is too low
100 2015-09-22 13:38:04 <morcos> that seems to make sense to me, and maybe the only inconsistency in the existing code is that you get rate limited if you're a "free" transaction wihtout your delta even if you're not "free" with your delta
101 2015-09-22 13:38:34 <morcos> i think it might make sense to rework how the deltas are applied
102 2015-09-22 13:39:24 <morcos> since presumably we will want to take those into account for mempool sorting, they need to be stored in the entry itself
103 2015-09-22 13:39:42 <morcos> we could still have the mapDeltas to represent txs which we might not have seen yet
104 2015-09-22 13:40:05 <morcos> but before i go to all this trouble, i'd like to understand that we're heading in the right direction
105 2015-09-22 13:41:29 <morcos> correction above: behave excactly as if their actual fee included that delta also
106 2015-09-22 13:42:47 <morcos> another question is does anyone care about using the mapDeltas prioritization to apply a delta to priority?  can i remove that?
107 2015-09-22 14:50:14 <wumpus> I'm not sure who uses that functionality - at least Luke-Jr does
108 2015-09-22 14:51:03 <hearn> morcos: i think there are pools that let you submit transactions to them privately who use that rpc
109 2015-09-22 14:51:11 <hearn> morcos: i could not name them though. it's just 'heard on the grapevine'
110 2015-09-22 14:54:46 <morcos> hearn: wumpus: thanks. understanding exactly what the use case is will help in figuring out how to move the functionality into the new sorted mempool world.  for instance if there are only ever very few entries in the map, then maybe the sort comparator can look in there?  if there are a lot of entries, then it needs to be an extra field in the CTxMempoolEntry or another index. or maybe the sort doesn't include it and there
111 2015-09-22 14:55:26 <morcos> doesn't include it and there is some special casing in the mining code
112 2015-09-22 14:55:56 <morcos> to pick out those transactions.  these questions apply both for the eviction sort now and the mining sort we're planning on implementing
113 2015-09-22 14:56:01 <morcos> sorry, irc fail
114 2015-09-22 15:22:40 <dcousens> morcos: fwiw,  I think the fee estimate PR is probably worthwhile
115 2015-09-22 15:22:56 <dcousens> it just had some side effects I don't think were clear to begin with, and I just wanted to put them out there
116 2015-09-22 15:23:12 <dcousens> I don't personally use the fee estimation from BTC core enough atm to have a strong opinion either way
117 2015-09-22 15:23:16 <morcos> dcousens: i'm glad you're taking an interest.  hardly anyone cares about how the fee estimation works at all
118 2015-09-22 15:23:56 <morcos> going forward its just going to become both more important and more complicated...
119 2015-09-22 15:24:10 <dcousens> morcos: probably because its black magic,  and the idea of a run-away fee estimate is a bit scary :S
120 2015-09-22 15:24:39 <morcos> yes, the idea that fee estimates could have a bad feedback loop which causes everyone to place higher and higher fees
121 2015-09-22 15:24:50 <morcos> bramc is concerned about that
122 2015-09-22 15:25:08 <dcousens> morcos: ooi, if you put it at 100% (vs 95%), would it approach infinity
123 2015-09-22 15:25:09 <dcousens> ?
124 2015-09-22 15:25:28 <morcos> i think for the most part though, the most practical concern now is to limit the number of cases where its just badly wrong by not being enough
125 2015-09-22 15:25:41 <morcos> i.e. you put on fee expecting to be confirmed in 2 blocks and it takes 100 blocks
126 2015-09-22 15:25:54 <morcos> without RBF, thats a really annoying situation to end up in
127 2015-09-22 15:26:30 <morcos> dcousens: not exactly  (approaching infinity)
128 2015-09-22 15:27:02 <morcos> its never going to return a result which is higher than some transactions on the network are occurring at
129 2015-09-22 15:27:30 <morcos> but it might give -1
130 2015-09-22 15:27:33 <dcousens> I haven't utACK'd the code yet because I haven't spent enough time reading how the actual algorithm works yet
131 2015-09-22 15:27:45 <morcos> which could lead people to place higher and higher fees on their transactions
132 2015-09-22 15:28:36 <morcos> there are i think more realistic practical concerns than a bad feedback loop right now
133 2015-09-22 15:28:50 <morcos> for instance what if ordering strictly by fee rate isn't exactly how miners prioritize things
134 2015-09-22 15:30:19 <morcos> and its super complicated to start thinking about CPFP type miner prioritization
135 2015-09-22 15:30:41 <dcousens> heh
136 2015-09-22 15:30:43 <dcousens> yeah
137 2015-09-22 15:30:46 <morcos> right now the code just ignores all transactions that couldn't be mined immediately on their own (have unconfirmed parents)
138 2015-09-22 15:31:52 <morcos> eventually hopefully the code will be modular enough that just like you could plug in different wallets to your full node, you could plug in different fee estimators
139 2015-09-22 15:31:56 <morcos> but thats a fantasy future
140 2015-09-22 15:32:45 <dcousens> morcos: I wonder if it'd ever be worth including an advertised fee rate on behalf of miners
141 2015-09-22 15:32:53 <dcousens> like, in the block headers or something
142 2015-09-22 15:33:31 <morcos> i'm not sure how such a thing would work...  miners can't live up to it necessarily if there isn't enough block space
143 2015-09-22 15:34:07 <dcousens> morcos: no doubt, just random ideas.  It'd also be impossible to guarantee as miners can't guarantee blocks, so it'd vary block-to-block anyway
144 2015-09-22 15:34:11 <morcos> i do think that the network is going to be healthier if there is a diversity of fee estimation algorithms
145 2015-09-22 15:34:38 <dcousens> morcos: it would reach a more natural equilibrium I supporse
146 2015-09-22 15:34:40 <dcousens> suppose*
147 2015-09-22 15:34:55 <morcos> an argument for exposing more knobs on what's in core
148 2015-09-22 16:06:49 <bsm1175321> I want security knobs, for different network/security assumptions than "6 confirmations".  Give me a probability instead...
149 2015-09-22 16:17:46 <gmaxwell> bsm1175321: one cannot generally reason about _security_ in a simple probablistic framework, and its usually wrong headed to try.
150 2015-09-22 16:18:06 <Luke-Jr> morcos: anything that assumes a specific policy would be problematic IMO
151 2015-09-22 16:20:17 <gmaxwell> bsm1175321: if you have a billion pixels on your webpage and due to a bugclicking a specific one sends the clicker 1BTC from your wallet. You have 100 BTC. You normally get 100 visitors a day, and each visitor clicks 10 times. What is your expected wallet balance tomorrow? ...  almost everything I just said is meaningless, the only thing to ask is how likely is it for an attacker to notice and care..
152 2015-09-22 16:20:23 <gmaxwell> . and thats mostly a property of the attacker not the site.
153 2015-09-22 16:21:28 <bsm1175321> gmaxwell: "6 confirmations" is absolutely an attempt to reason about security, and everyone uses it, and it's flawed.  That's my point.
154 2015-09-22 16:22:20 <bsm1175321> It can be improved.  e.g. How much hashpower does the largest miner have?  The largest two?  Let me assume they're colluding?  I can also measure how far my tx has propagated and how many nodes have it.  etc.  All of that could be fed into a better probabilistic security model.
155 2015-09-22 16:23:24 <gmaxwell> No most businesses (not to mention people) use even lower thresholds than 6 in my expirence.
156 2015-09-22 16:23:44 <bsm1175321> True, but they're all using wild-assed guesses.
157 2015-09-22 16:23:52 <bsm1175321> And hopes and wishes.
158 2015-09-22 16:24:21 <gmaxwell> Feel free to go do that math, you find that you need something like 50 to infinity confirmations to make non-trivial payments negative utility to attack assuming that hashpower distribution; which is uh. Not that helpful.
159 2015-09-22 16:24:27 <bsm1175321> If I'm going to transfer US $1M, I'd like to compute the expectation value of loss as P*value.
160 2015-09-22 16:25:31 <bsm1175321> Can you elaborate on "non-trivial payments negative utility to attack"?
161 2015-09-22 16:26:22 <gmaxwell> bsm1175321: again, you can't compute attacks as _probablities_.  There is not a magical attack fairy that rolls dice and only attacks when it comes up snake eyes.
162 2015-09-22 16:26:26 <btcdrak> gmaxwell: even some exchanges rely on just 1 confirmation (most Chinese exchanges for example)
163 2015-09-22 16:26:31 <gmaxwell> You can compute attacker utilities however.
164 2015-09-22 16:27:29 <btcdrak> gmaxwell: most of the other exchange are trusting 2 or 3 confirms.
165 2015-09-22 16:27:33 <bsm1175321> For a given security model, I can compute probabilities.  Of course there are many models and many possible attack vectors, so many answers to "probability".
166 2015-09-22 16:27:33 <gmaxwell> e.g. under assumptions will the attacker have a positive reward from this attack. And then bet that attackers are rational.
167 2015-09-22 16:29:11 <gmaxwell> bsm1175321: best of luck to you then.
168 2015-09-22 16:29:56 <bsm1175321> I'd like to see a more concerted effort to have security models proposed and used.  Guessing about confirmations is worse.
169 2015-09-22 16:30:29 <morcos> Luke-Jr: Would you mind giving me a summary of how miners use the prioritizeTransactin funtionality.  All I'm trying to do now is make it so they have access to at least the same functionality going forward that they do now.
170 2015-09-22 16:30:33 <bsm1175321> gmaxwell: Do you really think it's better to let everyone just make guesses?  At some point someone has to do quantitative risk analysis.
171 2015-09-22 16:31:40 <morcos> If there are miners that apply deltas to every transaction that comes in or we assume thats a use case we want to support it has different implicatiosn for design than if its just a few transactions that are manually prioritized
172 2015-09-22 16:32:29 <morcos> also its not clear to me whether a transaction with a small fee delta applied should still be able to be evicted and if so, does its fee delta need to be save in case it comes back to the mempool
173 2015-09-22 16:35:06 <wumpus> bsm1175321: I'm sure gmaxwell isn't trying to imply that, more like: if you think that's important, and feasible, work on it. What doesn't work is to go in here and state what you think is important, and then assume someone will pick it up.
174 2015-09-22 16:35:28 <bsm1175321> wumpus: not my goal.  I intend to implement it myself.
175 2015-09-22 16:35:33 <gmaxwell> bsm1175321: I think you're having a hard time listening because I'm not telling you what you want to hear. I've done the math, under pessimistic assumptions (like income maximizing rational miners, who are paying you and everyone else in their blocks, and have decided they will attack so long as its profitable to do so) with current hashrate distributions high value transactions have negligble securi
176 2015-09-22 16:35:39 <gmaxwell> ty until enormous numbers of confirms. In practice users don't even wait 6.  Now, if you'd like to go crunch on the numbers I expect you'll find exactly the same results as me. Or perhaps you won't! in either case complaining in here accomplishes nothing.
177 2015-09-22 16:36:05 <Luke-Jr> morcos: I've only seen it used for "be sure to mine this tx in the next block" and "don't mine this tx"; but that's independent from the functionality they have.
178 2015-09-22 16:36:37 <morcos> ah don't mine, hadn't thought about that
179 2015-09-22 16:36:49 <morcos> ok, and what about applying a delta to the priority
180 2015-09-22 16:36:59 <morcos> is that something anybody cares about?
181 2015-09-22 16:37:47 <bsm1175321> gmaxwell: "with current hashrate distributions" -- do you mean because of current mining centralization?
182 2015-09-22 16:38:11 <Luke-Jr> morcos: I care about preserving miner policy flexibility.
183 2015-09-22 16:38:50 <bsm1175321> gmaxwell: If so, that's an interesting, and I think believable result.
184 2015-09-22 16:38:52 <morcos> Luke-Jr: understood and agree.  But its not clear to me what additionaly flexibility you get by being able to apply a delta to priority rather than just fee
185 2015-09-22 16:39:07 <Luke-Jr> morcos: so if a miner wanted to mine only the newest spam, a hard-coded mempool policy evicting based on fee would probably counter-act that in a way that made it difficult for the miner's policy to work.
186 2015-09-22 16:39:29 <gmaxwell> bsm1175321: yep. Actually last time I crunched this was sometime back but the results should be similar now.
187 2015-09-22 16:40:09 <bsm1175321> gmaxwell: Disappointing.  I assume these results improve with less centralization?
188 2015-09-22 16:40:51 <gmaxwell> bsm1175321: I don't disagree with having analysis or anything but at least what I found is that any conservative model (e.g. didn't depend overly on honesty of miners; or assuming you were the only party being attacked) had uselessly large results such that everyone would ignore them. :(
189 2015-09-22 16:41:01 <gmaxwell> bsm1175321: yes. Assuming the attacker can't get much hashpower is a huge boon.
190 2015-09-22 16:41:06 <bsm1175321> I have a pile of ideas to help decentralize mining.  I'll concentrate on those over security calculations then... ;-)
191 2015-09-22 16:41:34 <morcos> Luke-Jr: OK thanks.  If you can provide me any more information at all about how you think this should work, it would be helpful.  Feel free to shoot me an email or soemthing if too long for IRC.
192 2015-09-22 16:42:20 <gmaxwell> bsm1175321: the other problem with these metrics is that they require being able to measure mining decenteralization; which you cannot reliably do within the system (except, with honest behavior from miners)
193 2015-09-22 16:43:25 <bsm1175321> Indeed.  Well one can dis-incentivize centralization and use e.g. amiller's nonoutsourceable puzzles.
194 2015-09-22 16:52:58 <sdaftuar> sipa: taking a look into the issue you reported regarding the mempool
195 2015-09-22 16:55:48 <sdaftuar> sipa: can you paste or email more of your debug.log?  i don't see a disconnect block on my nodes at that time
196 2015-09-22 18:47:06 <nwilcox> bsm1175321: Do you have a brain dump link of your ideas for decentralizing mining?
197 2015-09-22 18:48:40 <bsm1175321> Nothing I'm willing to share yet.  :-/  But happy to discuss ideas.
198 2015-09-22 18:49:34 <bsm1175321> But read this: http://blog.sldx.com/three-challenges-for-scaling-bitcoin/
199 2015-09-22 18:51:06 <nwilcox> Ok. I don't have any tangible thoughts here for bitcoin, but it's a topic I want to keep up on.
200 2015-09-22 18:55:48 <bsm1175321> I don't have a concrete proposal (working on it).  But requiring transactions to be mined on submission and relay moves mining to the edges of the network.  That's the general idea -- requiring a PoW hash on literally everything, probably combined with some form of merged mining for blocks.
201 2015-09-22 19:12:33 <Chojin> hhiya
202 2015-09-22 19:25:12 <dgenr8> Luke-Jr morcos: preserving miner policy flexibility means that the network cannot hope to optimize for miners' objectives, so it should not try.
203 2015-09-22 19:25:19 <dgenr8> The network should be selfish and optimize for its own goals
204 2015-09-22 19:26:45 <gmaxwell> dgenr8: you mean guarentting an income advantage for larger, more centeralized, miners who can afford to author or buy code that isn't hostile to their own interests, enh?  ... consistency and fairness are critical goals for the network.
205 2015-09-22 19:27:56 <dgenr8> i mean prioritizing transactions that are expected to cost the network the least
206 2015-09-22 19:29:39 <dgenr8> which does happen to be tied pretty strongly to fees - but is not directly equivalent to sorting by fee/kb
207 2015-09-22 19:34:53 <dgenr8> gmaxwell: if I understand you, it can be handled by having a DefaultMinerPolicy and a DefaultFullnodePolicy
208 2015-09-22 19:58:42 <Luke-Jr> seems like Travis is having like 10% intermittent failure
209 2015-09-22 20:01:51 <Tebbo> is everyone talking about the 21?
210 2015-09-22 20:02:04 <Luke-Jr> not here.
211 2015-09-22 20:02:08 <Tebbo> I'm wondering how good it is a dev platform compared to rpi
212 2015-09-22 20:02:12 <Tebbo> specifically for tx's
213 2015-09-22 20:02:25 <Tebbo> 400 is  a bit pricey for a tx machine
214 2015-09-22 20:02:44 <Tebbo> still haven't gotten my rpi tx machine to work tho :P
215 2015-09-22 20:05:08 <Luke-Jr> Tebbo: I meant to imply that this topic is not appropriate for this channel.
216 2015-09-22 20:16:52 <Luke-Jr> wumpus: how do I get the calendar in a standard format?
217 2015-09-22 20:32:26 <Tebbo> what's the best way to code in bitcoin?
218 2015-09-22 20:32:31 <Tebbo> right now i'm using the golang library
219 2015-09-22 20:32:39 <Tebbo> but if there's a better way maybe I should reconsider
220 2015-09-22 20:33:01 <wumpus> Luke-Jr: a standard format, like which?
221 2015-09-22 20:33:08 <Luke-Jr> ical or whatever.
222 2015-09-22 20:33:40 <wumpus> Tebbo: how do you mean 'code in bitcoin'?
223 2015-09-22 20:33:53 <Tebbo> use the protocol
224 2015-09-22 20:34:05 <wumpus> for random experiments I like petertodd's python-bitcoinlib
225 2015-09-22 20:34:06 <Tebbo> read pub keys, make txs, use wallets, etc
226 2015-09-22 20:34:31 <wumpus> but it just depends on what your favourite language etc is, if you want to use golang then use golang? :p
227 2015-09-22 20:34:41 <Tebbo> i mostly code web
228 2015-09-22 20:34:49 <Tebbo> but i'm coding an rpi application
229 2015-09-22 20:35:02 <Tebbo> so i don't want it to use a web service
230 2015-09-22 20:41:04 <wumpus> Luke-Jr: I could export a "Bitcoin-dev_11pqvdgpd99nlibf9ba861vu8s@group.calendar.google.com.ics": http://hastebin.com/ozedajihuc.txt
231 2015-09-22 20:41:40 <Luke-Jr> wumpus: hmm, no live link from Google? :/
232 2015-09-22 20:43:17 <wumpus> I don't think so - this was a zip I had to export and download and extract separately
233 2015-09-22 20:46:26 <wumpus> but there may be a better way (for example, through an API). I don't know
234 2015-09-22 20:47:11 <Luke-Jr> maybe easier if I just add it manually and update as needed
235 2015-09-22 22:56:05 <jgarzik> Need to extend Travis to run some nodes with various code
236 2015-09-22 22:56:24 <jgarzik> surely there are funds from all these wonderful startups to pay for some VMs
237 2015-09-22 23:38:07 <CodeShark> where should the versionbits activation states be persisted? would it make sense to track them in the CChain class at runtime?