1 2015-09-04 00:04:15 <jtimon> Luke-Jr: left responses
  2 2015-09-04 00:06:19 <jtimon> Luke-Jr: seriously, what's wrong with blindly accepting everything as the interface CPolicy that is not even used as default (not even for tests yet)
  3 2015-09-04 00:06:32 <jtimon> ?
  4 2015-09-04 00:07:32 <jtimon> CStandardPolicy, which is the default policy uses all the parameters you want in its contructor
  5 2015-09-04 00:08:32 <jtimon> but CRandomPolicy won't extend CStandardPolicy because it only has a -random_policy_accept_probability runtime parameter
  6 2015-09-04 00:09:33 <btcdrak> Luke-Jr: I updated the readme https://github.com/bitcoin/bips/pull/189
  7 2015-09-04 00:10:39 <jtimon> Luke-Jr: so it is better off extending a return true CPolicy for cases methods where bool is not being returned (ie: future but deprecated at born CPolicy::GetMinRelayFee())
  8 2015-09-04 00:12:04 <jtimon> gmaxwell: eric lombrozo is the author of the bip::layer attribute BIP
  9 2015-09-04 00:12:14 <jtimon> now that I remember
 10 2015-09-04 00:42:25 <jtimon> Bitcoin RT benevolent dictator: that's a very good question: yes, Bitcoin RT is intended to be backards-compatible even with the first released version of bitcoin software, in fact, RT will release a eventually release backards-compatible minor version on top of all bitcoin-satoshi-to-core major versions ever released. Starting with 0.11 one step at a time, 0.10 backwards rebase should be useful for elements, 0.9 rebase should be
 11 2015-09-04 00:42:25 <jtimon> Excited gitcloner: But, isn't the achronym backards?
 12 2015-09-04 00:42:25 <jtimon> phantomcircuit: I got it Bitcoin RT (Tenacious Review-beagging) {and I may be able to a-legally [can I use this prefix before any english word?] reuse Russia Today's logo}:
 13 2015-09-04 00:42:25 <jtimon> sueful for freicoin (if we ever get freicoiners to test freicoin-0.9) and 0.8 would be useful for additional assurance in freicoin-0.8-to-0.9 and the laziest bip66 adopters
 14 2015-09-04 00:43:17 <phantomcircuit> jtimon, ha im thinking they wont be amused by that
 15 2015-09-04 00:47:16 <jtimon> earlest versions will be supported by adding a "please plug back into the interwebs again and upgrade to a $minimal-safest-local-policy-defined-commit-id and to ubuntutu.org/master/windows10_skin ASAP!?!!!"
 16 2015-09-04 00:48:58 <jtimon> but it won't be triggered by a centralized multisig, it will be triggered by any transacation willing to spend an absrud fee
 17 2015-09-04 00:49:05 <jtimon> "absurd"
 18 2015-09-04 00:50:32 <jtimon> so bitcoin gt has to rebase a dynamic minimum relay fee back to the genesis branch, challenge accepted
 19 2015-09-04 00:53:48 <jtimon> phantomcircuit: we should continue our bitcoin gt discussion about bikes and colours in some other channel to not disturb this one
 20 2015-09-04 00:57:10 <phantomcircuit> heh
 21 2015-09-04 00:58:21 <rusty> https://gist.github.com/rustyrussell/47eb08093373f71f87de <- Modified version bits bip.  Uses retarget boundaries, explicit fallow period.  Will post to -dev soon.
 22 2015-09-04 00:59:48 <rusty> sipa's comments merged, it's now clearer.
 23 2015-09-04 01:02:08 <moa> anyone reserved XP ... that never gets upgraded
 24 2015-09-04 01:02:10 <moa> ?
 25 2015-09-04 01:05:50 <jtimon> rusty: are you working on version bits, awesome! that's a requirement for bip99's uncontroversial hardfork proposal!
 26 2015-09-04 01:06:23 <rusty> jtimon: it's a spare time project... but since LN, too, wants three soft forks, it's related :)
 27 2015-09-04 01:18:21 <KrellanWk> rusty: Nice use of bitmap for version bits, lots of altcoins do that already for selecting various flags
 28 2015-09-04 01:19:01 <phantomcircuit> gmaxwell, ha, this has been at ~97% complete for almost two days now
 29 2015-09-04 01:25:25 <gmaxwell> rusty: Have you computed the probablity that a proposal with 2/2016 support will falsely hit start and falsely hit abandonment?  might be interesting to see a table of hashrate percent P(start) per retarget, P(start) per year, P(abandon) per restart, P(abandon) per year, and the two products.
 30 2015-09-04 01:27:52 <rusty> gmaxwell: I've been cheating, using wolfram alpha.  Let me get that figure for you...
 31 2015-09-04 01:29:39 <rusty> gmaxwell: http://www.wolframalpha.com/input/?i=probability+of+10+or+more+successes+in+2016+trials+with+p%3D2%2F2016 => 0.000045
 32 2015-09-04 01:30:35 <rusty> (Then a 41% chance of abandonment)
 33 2015-09-04 01:34:33 <gmaxwell> I guess it would be interesting to know what true hashrate has the highest possibility of a start+abandon.  Lower rates are more likely to abandon, but less likely to start, there is some number that maximizes the odds.
 34 2015-09-04 01:36:13 <alpalp> I'd be happy to write some sims on it
 35 2015-09-04 01:48:14 <rusty> alpalp: that'd be good.  The math isn't really that hard; if you use bignums you can do it naively, even.
 36 2015-09-04 01:48:55 <alpalp> Just need the rules to follow
 37 2015-09-04 01:49:05 <rusty> gmaxwell: my gut says somewhere between 1 and 2 / 2016.
 38 2015-09-04 01:49:19 <alpalp> What triggers start/abandonment? I missed that part.
 39 2015-09-04 01:49:48 <rusty> alpalp: 10 blocks in 2016 triggers start.  < 2 in 2016 triggers abandonment.
 40 2015-09-04 01:50:01 <alpalp> is the 2016 rolling or fixed?
 41 2015-09-04 01:50:05 <rusty> alpalp: fixed.
 42 2015-09-04 01:51:35 <alpalp> rusty: I'm missing context some - something triggers first time it hits 10 blocks out of 2016, then as long as it stays >10, it is "Active" until it hits <2?
 43 2015-09-04 01:51:43 <rusty> alpalp: I think it's fair to only simulate abandonment immediately following start.  That's 4 weeks, and I think it's reasonable that more people would support the soft fork following that.
 44 2015-09-04 01:51:54 <rusty> alpalp: https://gist.github.com/rustyrussell/47eb08093373f71f87de
 45 2015-09-04 01:52:11 <alpalp> rusty: perfect, the piece i was missing
 46 2015-09-04 01:52:15 <alpalp> gonna take a look
 47 2015-09-04 01:52:58 <rusty> alpalp: IIRC, P(k of N) = (N! / (k!(N-k)!)) * p^k * (1-p)^(N-k).
 48 2015-09-04 01:53:32 <alpalp> Obviously will assume support level is constant
 49 2015-09-04 01:53:51 <alpalp> Gotta dust off my combinatorics but ill get it.
 50 2015-09-04 01:53:54 <gmaxwell> rusty: not sure about that assumption, if you look at past softforks there were long-ish periods of low levels of support. ... it's not like people rush to deploy new software (for good reason).
 51 2015-09-04 01:54:21 <gmaxwell> I dunno that longer periods will matter but I think all periods up to the timeout are interesting.
 52 2015-09-04 01:54:55 <alpalp> If the true support rate was very close to 2 to 10/2016, you could see start -> abandoned after an extended period of time
 53 2015-09-04 01:55:11 <rusty> gmaxwell: so up to (say) 26 periods.  Seems fair to look at worst case.
 54 2015-09-04 01:55:18 <alpalp> In fact, it would in the long run almost always hit an unlucky streak and get abandoned
 55 2015-09-04 01:57:04 <alpalp> for example, Say you had 10/2016 hash rate supporting, it would activate very likely within 2-3 periods
 56 2015-09-04 01:57:14 <rusty> alpalp: 10/2016 gives P(starting) 0.54, but P(abandoning) 0.000489.
 57 2015-09-04 01:57:48 <alpalp> So P(not abandoning over 26 periods) = (1-.0000489)^26
 58 2015-09-04 01:57:56 <rusty> alpalp: See http://www.wolframalpha.com/input/?i=probability+of+10+or+more+successes+in+2016+trials+with+p%3D10%2F2016&dataset=&equal=Submit and   http://www.wolframalpha.com/input/?i=probability+of+fewer+than+2+successes+in+2016+trials+with+p%3D10%2F2016
 59 2015-09-04 01:58:26 <gmaxwell> alpalp: which isn't so bad.  but you added an extra zero
 60 2015-09-04 01:58:35 <gmaxwell> though thats also not so bad.
 61 2015-09-04 01:58:44 <rusty> alpalp: 98.7%
 62 2015-09-04 01:58:56 <alpalp> I am getting 88% chance of not abandoning
 63 2015-09-04 01:59:14 <alpalp> wait
 64 2015-09-04 01:59:17 <alpalp> you were right
 65 2015-09-04 01:59:24 <alpalp> so easy enough to make a table for this
 66 2015-09-04 01:59:26 <gmaxwell> yea, I get 0.987363411159549
 67 2015-09-04 01:59:55 <alpalp> I can get a table of it pretty easily
 68 2015-09-04 02:00:37 <rusty> alpalp, gmaxwell: If numbers get too close we could increase the 10 threshold; basically 1% seems fair, which would be 20.  I totally made the numbers up ;)
 69 2015-09-04 02:01:38 <alpalp> What happens before starting
 70 2015-09-04 02:01:49 <alpalp> It seems like that bit would be reserved anyway, the only thing it does is give the chance to be abandoned
 71 2015-09-04 02:02:02 <gmaxwell> rusty: well you have to worry about zombies. Your timeout doesn't start until it reaches starting state.
 72 2015-09-04 02:02:12 <rusty> alpalp: if it's never observed, we can't say much about that.
 73 2015-09-04 02:02:56 <gmaxwell> how bad are zombies? e.g. if something has 10% support, and squats the bit forever... I guess thats not really an issue. to get the bit back you just get people to stop, and then it will hit abandoned.
 74 2015-09-04 02:03:04 <rusty> gmaxwell: we actually don't need that any more with the fallow period.  But it stop people putting guesstimate numbers in bips :)
 75 2015-09-04 02:03:27 <rusty> gmaxwell: ie. "Timeout 1 year from September".
 76 2015-09-04 02:03:51 <alpalp> gmaxwell: it seems worse if it has even less support and never gets activated.
 77 2015-09-04 02:04:50 <rusty> gmaxwell: yeah, if people don't stop setting the bit, no protocol works very well AFAICT.  But increasing the noise threshold worsens the abandonment problem.
 78 2015-09-04 02:05:11 <gmaxwell> alpalp: I was talking about a low support BIP that doesn't hit abandonment, timeout, or activation.  rusty suggested increasing the starting threshold, which would make that more likely as you can't be abandoned if you don't start. :)
 79 2015-09-04 02:05:58 <gmaxwell> but on more consideration it would probably be fine. Really a starting threshold of 50% would perhaps even be reasonable. Rationale, no soft-fork with less than 50% can be viable.
 80 2015-09-04 02:06:00 <alpalp> gmaxwell: Yes, it seems like that's a worse problem- better to start it and let it get abandoned.
 81 2015-09-04 02:06:29 <gmaxwell> alpalp: hm. I thought I just convinced myself that it wasn't a problem.
 82 2015-09-04 02:06:31 <alpalp> Unless I am missing the point somehow - seems like the point is to test if something has any interest, and scrap it if it has very little
 83 2015-09-04 02:07:07 <gmaxwell> I've probably forgotten why it has these extra states. :(
 84 2015-09-04 02:07:12 <alpalp> gmaxwell: might it make more sense to have increasing limits to avoid abandonment?
 85 2015-09-04 02:08:01 <alpalp> rusty: that formula you had I believe is for only exactly k, you need a summation to get that or more (or that or less).
 86 2015-09-04 02:08:14 <alpalp> which makes simulation a lot easier in some of these cases
 87 2015-09-04 02:08:14 <rusty> alpalp: indeed...
 88 2015-09-04 02:08:20 <gmaxwell> My understanding is that rusty added the extra states because he wants to have a clear programmed universal starting time for the timeout.
 89 2015-09-04 02:09:26 <rusty> gmaxwell: yes.  Otherwise, how does random BIP author set the timeout?
 90 2015-09-04 02:09:31 <gmaxwell> and to get that you need a started state, but I don't think you need an abandoned state. The abandoned state is so that you can timeout faster than the time out in some cases.
 91 2015-09-04 02:10:21 <alpalp> I wonder if some type of voting against signal would be more useful
 92 2015-09-04 02:10:24 <gmaxwell> rusty: randomly. e.g. with a fixed date.
 93 2015-09-04 02:10:33 <gmaxwell> alpalp: please no, thats a misunderstanding.
 94 2015-09-04 02:10:46 <rusty> gmaxwell: I've seen how well that works with the recent 1xx bips.  Badly.
 95 2015-09-04 02:11:05 <alpalp> gmaxwell: More thinking along the lines of if you knew the majority of miners rejected it, you could move on
 96 2015-09-04 02:11:20 <gmaxwell> Versionbits is not a "vote" its quorum sensing to determine the safty of enforcing a rule. People say if they'll enforce if a quorum is sensed, anyone who doesn't say that is giving a very powerful 'vote' against.
 97 2015-09-04 02:11:23 <alpalp> whereas they might just not care/not have upgraded/not know enough yet
 98 2015-09-04 02:11:29 <rusty> gmaxwell: we could drop the abandoned state, but it kind of came for free with the idea of a fallow period prior to activation.
 99 2015-09-04 02:11:30 <gmaxwell> alpalp: oh interesting, for fast abandonment.
100 2015-09-04 02:11:40 <gmaxwell> alpalp: sorry, I was falling into a repetative response there.
101 2015-09-04 02:12:17 <gmaxwell> rusty: perhaps, it's an extra set of code paths which will probably not be adequately tested in most implementations.
102 2015-09-04 02:12:21 <alpalp> gmaxwell: no worries.  Just thinking out loud - seeing if a tri-state yes/no/nothing was more useful than yes/nothing.
103 2015-09-04 02:12:59 <gmaxwell> alpalp: not worth the extra bit in any case, all fast abandonment gets you is the bit back faster.
104 2015-09-04 02:13:12 <gmaxwell> rusty: so I'm actually not sure that your scheme prevents the need for arbritary dates in the BIPs.
105 2015-09-04 02:13:41 <alpalp> gmaxwell: Could you have an escalating set of thresholds needed to stay alive once activated?
106 2015-09-04 02:14:17 <gmaxwell> rusty: so what happens if  I deploy a BIP, it doesn't reach start (regardless of if start is 10 or 20). and then two years later someone deploys a different bip on the same number. And now my implementation will falsely trigger on it.
107 2015-09-04 02:14:29 <gmaxwell> alpalp: one could but I don't know what value that would really have.
108 2015-09-04 02:14:38 <alpalp> getting faster abandonment
109 2015-09-04 02:14:47 <alpalp> though the need for >28 soft forks within a year seems a bit excessive
110 2015-09-04 02:14:51 <gmaxwell> rusty: so I think my BIP needs to stay that if it hasn't started by yyyy-mm-dd then it cannot start.
111 2015-09-04 02:15:18 <rusty> gmaxwell: your implementation has been setting that bit for two years.  It's not secret.  Ah, non-miners.. hmm...
112 2015-09-04 02:15:32 <gmaxwell> rusty: (or by height instead of date, same deal)
113 2015-09-04 02:15:46 <gmaxwell> basically I  think the same problem exists it's just been moved to start.
114 2015-09-04 02:16:16 <alpalp> gmaxwell: start is a good baseline since you dont know when the software will hit the miners
115 2015-09-04 02:16:17 <gmaxwell> the 'real' start which you cannot measure is the deployment of the software.
116 2015-09-04 02:16:35 <rusty> gmaxwell: you have a point.  But I think that start is a better spec than finish, because deployment.
117 2015-09-04 02:17:03 <gmaxwell> Yea, maybe, okay indeed. thats better.
118 2015-09-04 02:17:06 <rusty> gmaxwell: so, if it doesn't start by <year>, it's abandoned.
119 2015-09-04 02:17:15 <alpalp> Just have start defined as first seen of that bit perhaps, and 2-3 periods without anyone seeing it again is abandoned
120 2015-09-04 02:17:24 <gmaxwell> alpalp: no that doesn't work either.
121 2015-09-04 02:17:45 <gmaxwell> alpalp: consider, you deploy a bip, no one ever mines a single block with it, but perhaps lots of nodes deploy your code.
122 2015-09-04 02:17:58 <gmaxwell> alpalp: then later someone comes along and reuses the bit. all those nodes will trigger.
123 2015-09-04 02:17:59 <rusty> gmaxwell: we can drop the direct abandonment state, and have it only after timeout.  But they're the same case as written, so seemed minimal.
124 2015-09-04 02:18:23 <alpalp> gmaxwell: you'd still need some non-deployment related timeout too I suppose.
125 2015-09-04 02:18:30 <gmaxwell> alpalp: so I think there must be a time limit for starting, but I agree with rusty that it's better on start than finish.
126 2015-09-04 02:18:49 <rusty> gmaxwell: revising...
127 2015-09-04 02:19:07 <gmaxwell> Right you'd say in your bip/implementation that you can only start between X and Y.
128 2015-09-04 02:21:08 <alpalp> gmaxwell:  Then you could increase the initial start threshold and make abandon pretty low, but not quite as low
129 2015-09-04 02:21:23 <rusty> gmaxwell: well, X is implied in the actual approval of the BIP.  And I'm specifying Y in year granularity.
130 2015-09-04 02:21:26 <alpalp> just spitballing but say 25% to start, 5% to abandon might work.
131 2015-09-04 02:21:37 <gmaxwell> rusty: thats not how the bip process works
132 2015-09-04 02:21:46 <gmaxwell> BIPs are approved by actual deployment.
133 2015-09-04 02:22:14 <gmaxwell> I guess authorship of the BIP would work or something like that.
134 2015-09-04 02:22:42 <rusty> gmaxwell: yeah, I think X is artificial.  It's technically "on receipt of a unique version bit" I guess...
135 2015-09-04 02:23:23 <gmaxwell> rusty: yea. We still don't know how to allocate those things. there is a hope with two dozen that it's not much of an issue.
136 2015-09-04 02:23:25 <alpalp> X is useful if you are reusing a bit reserved by another
137 2015-09-04 02:27:06 <Luke-Jr> gmaxwell: could be allocated with the BIP number?
138 2015-09-04 02:29:40 <rusty> gmaxwell: OK, '''Soft Fork Nonstarter''' section added.
139 2015-09-04 02:30:09 <rusty> gmaxwell: now, want me to kill abandonment and see what that looks like?
140 2015-09-04 02:38:34 <kanzure> gmaxwell: for problems like "someone might start using the bit again in the future", you could have a standard where a transaction is made by the miner with information that clarifies the use of a recycled bit.
141 2015-09-04 02:41:05 <kanzure> "disambiguation transaction" :-/
142 2015-09-04 02:42:09 <rusty> kanzure: yeah, if this BIP fails, we could return to "random shit in coinbase"....
143 2015-09-04 02:43:04 <gmaxwell> well no, thats an interesting notion. That you could have an explicit abandonment procedure which was 'this coin get spent'.
144 2015-09-04 02:43:12 <gmaxwell> E.g. Bonded deployment.
145 2015-09-04 02:43:21 <kanzure> ah you can reference already-confirmed utxos
146 2015-09-04 02:43:56 <gmaxwell> e.g. when the BIP spec is published there is some extisting utxo it references and if not locked, the BIP is abandoned if that utxo is spent.
147 2015-09-04 02:44:07 <kanzure> who spends?
148 2015-09-04 02:44:09 <kanzure> bip author?
149 2015-09-04 02:44:18 <gmaxwell> And the utxo can be high value, to increase confidence that the thing gets spent.
150 2015-09-04 02:44:21 <kanzure> bip deployment coordinator should be someone else maybe
151 2015-09-04 02:44:50 <gmaxwell> kanzure: could be multisig for all I care, e.g. of major implementations that intend to ship the bip.
152 2015-09-04 02:44:57 <gmaxwell> But it's not very lite wallet compatible.
153 2015-09-04 02:45:02 <gmaxwell> not incompatible though.
154 2015-09-04 02:45:14 <kanzure> spend rule can be based on sliding window of checking coinbase transactions for switch or something
155 2015-09-04 02:45:30 <kanzure> </arbitrary rubegoldberg machine>
156 2015-09-04 02:46:13 <rusty> gmaxwell: to make that observable you need to reference it somehow on activation, too.
157 2015-09-04 02:47:03 <kanzure> "OP_CHECKCOINBASEFLAGVERIFY" (insufficiently descriptive)
158 2015-09-04 02:49:11 <kanzure> (it would have to be an opcode that checks coinbase bip flags over a sliding window- like the 1000 blocks that the bip can be activated during- and if it's not activated, then the balance can be spent or something)
159 2015-09-04 02:52:53 <kanzure> btw: how well-known are the "have some OP_NOPs return true and not return false" proposal? and what about the "have an OP_NOP extension set before we run out of OP_NOPs" proposal?
160 2015-09-04 02:53:22 <rusty> gmaxwell: OK, https://gist.github.com/rustyrussell/47eb08093373f71f87de now has two versions, the top is the "no abandonment" version.  I tried to use a branch, but gist doesn't seem to notice branches.
161 2015-09-04 04:10:04 <cfields> jtimon: i'm getting ready to head out of town for the weekend, but i'll catch up on the consensus PRs when i get back
162 2015-09-04 04:10:29 <cfields> sorry for the slow response lately, i've been really focused on the p2p rework, hoping to have something ready for montreal
163 2015-09-04 04:10:37 <cfields> sadly, that doesn't seem realistic :\
164 2015-09-04 04:13:17 <Luke-Jr> ☹
165 2015-09-04 05:49:15 <SeanAvery> hello
166 2015-09-04 11:07:37 <wumpus> went ahead and merged #5677, if you encounter any problems with RPC in master let me know
167 2015-09-04 12:02:51 <jonasschnelli> wumpus: what about adding a apache/ngnix/lighttpd revery proxy doc. Something like "How to use bitcoin-core RPC with apache mod_proxy and SSL?"
168 2015-09-04 12:03:09 <jonasschnelli> Place some example conf how to harden bitcoin rpc over SSL/Auth-Digest, etc.?
169 2015-09-04 12:08:56 <elguido_> Hi All
170 2015-09-04 12:09:11 <wumpus> HTTP Auth-Digest is terrible :) but sure, why not
171 2015-09-04 12:09:35 <elguido_> Is there anyone interrested in developping a new Coin currency ?
172 2015-09-04 12:10:15 <wumpus> elguido_: not the place here
173 2015-09-04 12:11:42 <elguido_> Thanks, could you recommend please ?
174 2015-09-04 13:39:45 <jgarzik> wumpus, is anyone working on using libevent for P2P yet?
175 2015-09-04 13:40:55 <jonasschnelli> jgarzik: cfields is
176 2015-09-04 13:41:22 <jgarzik> good
177 2015-09-04 13:42:25 <jonasschnelli> jgarzik: IIRC, he wants to have it ready (PoC level) for Montreal.
178 2015-09-04 13:42:33 <jgarzik> jonasschnelli, BTW, I was able to get standalone univalue repo working as a sub-tree in one of my other projects (rpcsrv)
179 2015-09-04 13:43:03 <jgarzik> jonasschnelli, probably needs some *.am/*.ac work before bitcoin can use it as a subtree
180 2015-09-04 13:44:35 <jonasschnelli> jgarzik: Maybe. Basic autoconf structure is already there. Not sure if this is sufficient thought. Will try to add it as bitcoin sub-tree soon.
181 2015-09-04 13:45:05 <jonasschnelli> Would be a good moment now because IIRC the both sources are in sync now.
182 2015-09-04 13:46:53 <jgarzik> yes
183 2015-09-04 13:47:47 <jgarzik> similar to libsecp256k1, the difficulty is getting the trees to build and test both embedded as a sub-tree and also when used independently.
184 2015-09-04 13:49:36 <jonasschnelli> jgarzik: in theory this should work with the --with-numfunc configuration variable i have added recently. Will try now...
185 2015-09-04 14:23:35 <jonasschnelli> jgarzik: this (https://github.com/jgarzik/univalue/pull/3) is required for UniValue repository to pass bitcoins uinvalue unittests
186 2015-09-04 14:24:51 <jgarzik> jonasschnelli, you forgot to "git add fail34.json"
187 2015-09-04 14:25:12 <jonasschnelli> jgarzik: beh! Fixed and force pushed.
188 2015-09-04 15:21:03 <nwilcox> Ages ago (2015-08-17) bedeho asked if the nHashType was covered by the signature, and I just answered that question for myself: https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L1099
189 2015-09-04 15:21:18 <nwilcox> Maybe if bedeho ever greps these logs for their alias, they'll see this answer.
190 2015-09-04 15:21:51 <nwilcox> Link summary: the nHashType is included in the hash input, which is a good thing (tm).
191 2015-09-04 15:35:44 <kanzure> weird, closing an issue while also referencing a pull request did not cause the mention to show up on the merged pull request comment feed https://github.com/bitcoin/bitcoin/issues/6454#issuecomment-137766407
192 2015-09-04 15:51:12 <kanzure> still interested in getting some opinions on this, how well-known are the "have some OP_NOPs return true and not return false" proposal? and what about the "have an OP_NOP extension set before we run out of OP_NOPs" proposal?
193 2015-09-04 15:51:16 <kanzure> or similar proposals
194 2015-09-04 15:51:30 <kanzure> also the above github weirdness has been reported to support@github.com
195 2015-09-04 16:08:15 <wumpus> yes "closing an issue while also referencing a pull request did not cause the mention to show up on the merged pull request comment feed" doesn't seem to be always reliable
196 2015-09-04 16:10:57 <jtimon> cfields: that's fine, I was just scared about #6526 getting merged too soon without my nits (#6625)
197 2015-09-04 16:21:14 <kuzetsa> I need better fueltanks :(
198 2015-09-04 16:21:27 <kuzetsa> and/or more than 30 parts permitted to build a rocket
199 2015-09-04 16:43:57 <kuzetsa> ok, so if I'm 3 minutes to SoI change (abount to enter the patched conics thinger for mun) and it says I'll do a flyby, and after the flyby my kerbin PE will be 44km
200 2015-09-04 16:44:03 <kuzetsa> how rubbish is that estimate?
201 2015-09-04 16:44:44 <kuzetsa> I have 625m/s dV left for making adjustments, but I kinda think I should wait to make adjustments until 5-10 minutes after leaving mun SoI???
202 2015-09-04 16:44:59 <kuzetsa> I haven't played in a couple months and can't remember how to do this stuff
203 2015-09-04 16:46:44 <kuzetsa> oh crap
204 2015-09-04 16:46:55 <kuzetsa> this isn't the KSP channel I thought I was in
205 2015-09-04 16:46:56 <kuzetsa> sorry :(
206 2015-09-04 16:46:57 <wumpus> kuzetsa: don't forget to put bitcoin nodes in orbit around moons and planets you fly by (btw, wrong chanel?)
207 2015-09-04 16:47:37 <wumpus> heh
208 2015-09-04 16:48:16 <kuzetsa> I wish someone had stopped me at "I need better fueltanks"
209 2015-09-04 16:48:27 <jonasschnelli> Hah... :-)
210 2015-09-04 16:49:24 <kanzure> actually i think we do have some rocketry expertise in here
211 2015-09-04 16:49:27 <kuzetsa> I do more game modding and android development (kernel hacking mostly) than bitcoin these days
212 2015-09-04 16:49:46 <kuzetsa> occasionally I manage to outright forget I ever used bitcoin & kept up with what was going on
213 2015-09-04 16:50:00 <kuzetsa> the politics of bitcoin scared me off, sadly :(
214 2015-09-04 16:50:51 <kuzetsa> anyway -- sorry again, I hadn't meant to offtopic so much
215 2015-09-04 17:00:07 <maaku> kuzetsa: there's more than a handful of aerospace nerds here
216 2015-09-04 17:02:06 <kuzetsa> maaku: fair enoguh -- I'm more into the space physics (orbital mechanics / optimizing the geometry and timing for maneuvers) than the aero side of "aerospace" :)
217 2015-09-04 17:03:33 <maaku> ok astronautics nerds :P
218 2015-09-04 17:04:56 <maaku> if you feel like developing a fleet of bitcoin-relay cubesats, it'd be much appreciated :)
219 2015-09-04 17:06:15 <maaku> this is actually more #bitcoin-wizards stuff, but there's some pretty cool things you could do with a constelation of federated timestamppers in orbit
220 2015-09-04 19:59:14 <warren> A computer science student is going to the Montreal workshop, asked if there is a single book or something she should read to get caught up on Bitcoin terminology and how it works before the event.  Any suggestions?
221 2015-09-04 19:59:51 <Luke-Jr> Bitcoin.org has some terminology guide thing, but I'm not sure how correct it is
222 2015-09-04 20:07:15 <sdaftuar> warren: _mastering bitcoin_ perhaps (caveat: i haven't read it myself)
223 2015-09-04 20:10:01 <warren> yeah, I think none of the devs that I know have vetted material for learners
224 2015-09-04 20:10:26 <warren> I'm just going to lazyweb it and ask reddit for recommendations.
225 2015-09-04 20:10:51 <kanzure> bitcoin.org is probably better at this point
226 2015-09-04 20:13:12 <warren> https://bitcoin.org/en/developer-guide#block-chain  ah... this stuff isn't too bad
227 2015-09-04 22:44:51 <phantomcircuit> cc1plus: out of memory allocating 65528 bytes after a total of 87109632 bytes
228 2015-09-04 22:44:52 <phantomcircuit> lol wat