1 2015-08-31 00:12:05 <asktodo> I need a system message for altcoin
  2 2015-08-31 00:19:48 <Luke-Jr> asktodo: ##altcoin-dev
  3 2015-08-31 01:54:36 <drazisil> What does "Operation not valid with the current stack size" mean when trying to sign a raw tx, and how do I fix it?
  4 2015-08-31 01:55:54 <drazisil> looking at the code it seems to fire if the stack is < 1, but I have no idea what would cause that.
  5 2015-08-31 02:01:38 <phantomcircuit> drazisil, if you call OP_CHECKMULTISIG twice you will get that
  6 2015-08-31 02:03:44 <drazisil> phantomcircuit: How would I know/see that being called in the raw tx?
  7 2015-08-31 02:04:10 <phantomcircuit> drazisil, decoderawtransaction
  8 2015-08-31 02:04:17 <phantomcircuit> which you should be doing before signing one anyways
  9 2015-08-31 02:04:33 <drazisil> phantomcircuit: which I did, it's here: https://gist.github.com/drazisil/26ab98ea999d11b51f77
 10 2015-08-31 02:05:53 <drazisil> I'll assume I goofed the createraw, but I don't see OP_CHECKMULTISIG
 11 2015-08-31 02:08:37 <drazisil> I used the redeamscript from the createmultisig, was that wrong?
 12 2015-08-31 03:36:47 <Luke-Jr> michagogo: ping (why is your git email invalid btw?)
 13 2015-08-31 10:08:05 <aphorise> join #norway
 14 2015-08-31 10:31:18 <phantomcircuit> gmaxwell, btw checkpoints are disabled when you reindex or load from -loadblock
 15 2015-08-31 10:40:53 <mjerr> Is there a reason bitcoin doesn't make use of the hole-punching technique to have nodes connect to other nodes even without ports forwarded?
 16 2015-08-31 10:41:59 <wumpus> mjerr: as usual "no one implemented it"
 17 2015-08-31 10:42:14 <hearn> mjerr: there's UPnP support
 18 2015-08-31 10:42:43 <mjerr> ah, so no fundamental obstacles at least ;)
 19 2015-08-31 10:42:45 <wumpus> also hole punching is for UDP, not TCP
 20 2015-08-31 10:43:14 <wumpus> ... I think that's a pretty fundamental obstacle
 21 2015-08-31 10:46:32 <mjerr> currently thinking about the network logistics of lightning nodes, especially since everyone should be a node and should be reachable by his chosen X nodes he does have a channel open. but how do we accomplish this on a network level, where nodes often may be smart phones with changing IPs and NAT
 22 2015-08-31 10:47:20 <wumpus> tor hidden services would work (see https://github.com/bitcoin/bitcoin/issues/6586)
 23 2015-08-31 10:47:43 <mjerr> oh I see and use roundevous points
 24 2015-08-31 10:47:48 <mjerr> for communication
 25 2015-08-31 10:48:51 <mjerr> I don't know out of my head how hidden services works out when you have a highly dynamic IP (as on 3G), but I guess the Tor curcuits do the heavy lifting there
 26 2015-08-31 10:49:28 <wumpus> they provide a way to 'listen' even when behind NAT or dynamic IP
 27 2015-08-31 10:50:46 <buZz> mjerr: eh, UPnP works
 28 2015-08-31 10:50:46 <wumpus> wouldn't know how it holds under highly dynamic IP either (eg if it changes every minute)
 29 2015-08-31 10:50:49 <hearn> mjerr: it's basically just a DHT run by a bunch of people
 30 2015-08-31 10:51:20 <wumpus> but I suspect it just works, as it doesn't depend on accepting incoming connections
 31 2015-08-31 10:52:23 <mjerr> wumpus, yea I guess the keep-alive timespan is really the limit for changing IPs when you are only listening
 32 2015-08-31 10:52:52 <phantomcircuit> wumpus, connections die but you're still connectable
 33 2015-08-31 10:56:15 <mjerr> doing connections this way, I really worry about latency though. given how 3g coverage can blow this already alone, adding these layers will make it even worse. especially brick-and-mortar salepoints wouldn't accept that
 34 2015-08-31 10:57:01 <wumpus> buZz: UPnP works if enabled on your router. It's great to have it as it results in more connectable nodes, but it's not something that can be relied on to be there and work
 35 2015-08-31 10:57:49 <wumpus> mjerr: well yes using tor is kind of heavy-handed, I'm sure if you provide your own rendezvous logic specific for the protocol you're implementing it could be faster
 36 2015-08-31 10:58:11 <wumpus> *if* you don't need the privacy that onion routing provides
 37 2015-08-31 10:58:32 <buZz> wumpus: many consumer routers come with it pre-enabled
 38 2015-08-31 10:58:57 <wumpus> buZz: sure, no one is arguing that that isn't the case
 39 2015-08-31 10:59:08 <buZz> ah k k, just sayin' its a viable option
 40 2015-08-31 10:59:12 <wumpus> that's why "it results in more connectable nodes" works
 41 2015-08-31 10:59:24 <wumpus> but you can't *rely* on it, e.g. require it to be able to accept payments
 42 2015-08-31 10:59:51 <buZz> well who cares about lightning nodes anyway
 43 2015-08-31 10:59:52 <wumpus> especially mobile phone NAT at providers certainly has no UPnP support
 44 2015-08-31 11:01:17 <mjerr> I think the privacy can always be included when needed. if everyone is connected to 5 nodes, routing to the cafe-node might require 3-5 hops. given one rendezvous in between, this would lead to around 10 connections (one way is good enough for this scenario to complete the payment, we can always clear the payment later).. given 100ms maybe per connection, 1s would still be okayish.. faster
 45 2015-08-31 11:01:17 <mjerr> than cash I think
 46 2015-08-31 11:02:59 <mjerr> most of these figuers are just made up though.. 5 hops isn't very much if everyone is strictly connected to 5 other nodes only, that is there are no real big payment hubs
 47 2015-08-31 11:05:30 <buZz> 0 confirms is not so useful
 48 2015-08-31 11:05:54 <mjerr> hm?
 49 2015-08-31 11:06:56 <mjerr> I somewhere read electronic payments has do be done within like <1s, but my experience - at least in europe - is that cc payments in stores take AGES very often
 50 2015-08-31 11:08:24 <buZz> most nations dont use CC at all
 51 2015-08-31 11:08:30 <buZz> its not useful to compare
 52 2015-08-31 11:08:36 <mjerr> yea, we use ec cards here aswell
 53 2015-08-31 11:08:43 <mjerr> but they are often even slower
 54 2015-08-31 11:09:06 <buZz> imho the only comparison that makes sense, is cash
 55 2015-08-31 11:14:50 <phantomcircuit> wumpus, you can drop the number of nodes per circuit to get lower latency
 56 2015-08-31 11:15:00 <phantomcircuit> tor hidden services are actually very fast
 57 2015-08-31 11:15:11 <phantomcircuit> the defaults jump through lots of hops though
 58 2015-08-31 11:15:38 <buZz> i2p ones are faster ;)
 59 2015-08-31 11:16:43 <mjerr> buZz, I am completely unable to find any studies on checkout-times for cc or cash :o
 60 2015-08-31 11:16:53 <buZz> mjerr: ask visa
 61 2015-08-31 11:17:00 <buZz> they will tell you cc is faster all the time
 62 2015-08-31 11:17:06 <buZz> then ask a mint
 63 2015-08-31 11:17:10 <buZz> they will tell you cash is faster all the time
 64 2015-08-31 11:17:16 <buZz> then, do your own research
 65 2015-08-31 11:17:44 <mjerr> yea, thats the general stuff that I find, I am looking for some real studies, which I think exists - because sales
 66 2015-08-31 11:18:56 <mjerr> phantomcircuit, the usual amount is 3 to RP from both sides, so 6 hops in total? but isn't this the minimal amount already?
 67 2015-08-31 11:19:29 <phantomcircuit> mjerr, if you dont actually care about being anonymous you can reduce the amounts
 68 2015-08-31 11:19:35 <phantomcircuit> maybe it wont let you anymore though
 69 2015-08-31 11:21:18 <mjerr> yes, so just having the RP as the only hop would be the minimum to have a connection, given privacy isn't a problem.. would still lead to a lot of hops, but I have to find some more meaningful numbers about what is actually acceptible as delay
 70 2015-08-31 11:27:25 <hearn> mjerr: payment latency is something BIP70 fixes
 71 2015-08-31 11:27:51 <hearn> mjerr: the gold standard is everything being done within ~400 msec, that's what you need for high capacity transit systems
 72 2015-08-31 11:27:56 <hearn> we are far from that today ....
 73 2015-08-31 11:39:55 <mjerr> everything is from where the POS terminal and the smartphone/cc comes into physical contact, right?
 74 2015-08-31 11:41:16 <mjerr> I think lightning can do that, but only with large centralized hubs
 75 2015-08-31 11:44:26 <phantomcircuit> mjerr, why do people keep saying that?
 76 2015-08-31 11:44:35 <phantomcircuit> nothing about the design in lightning would require centralized hubs
 77 2015-08-31 11:45:17 <mjerr> phantomcircuit, I never said we *need* them, I said 400ms is only achievable with them though
 78 2015-08-31 11:45:34 <phantomcircuit> mjerr, uh no
 79 2015-08-31 11:46:03 <phantomcircuit> 4 signature operations a hash and a few hundred bytes of data per hop
 80 2015-08-31 11:46:16 <phantomcircuit> maybe you're not going to get 400ms over tor
 81 2015-08-31 11:46:19 <hearn> mjerr: 400msec is easily achievable with bitcoin
 82 2015-08-31 11:46:24 <hearn> mjerr: well, not "easily", but doable.
 83 2015-08-31 11:46:41 <mjerr> given the latency and 3g coverage of some cities, 400ms might not even be enough to make the payment, even if you are directly paying the other hub
 84 2015-08-31 11:46:57 <hearn> mjerr: consider that you can send a packet over the atlantic in ~70msec, i think. or it used to be around that.
 85 2015-08-31 11:47:17 <mjerr> of course not over home internet, but 3g will be a problem - and I see that a lot of people will use smartphones for their node
 86 2015-08-31 11:47:49 <mjerr> computation is of course trivial
 87 2015-08-31 11:48:23 <mjerr> and the amount of data is small aswell, but establishing a connection in a crowdy place over 3g is an issue - not just for bitcoin/lightning, but for commercial solutions like apple pay aswell
 88 2015-08-31 11:48:46 <hearn> mjerr: what makes you think you need a 3G connection? this is all already handled by BIP70 and the bluetooth work andreas and I did years ago
 89 2015-08-31 11:49:04 <hearn> mjerr: you can open a bluetooth connection and splat a BIP70 Payment message to the other side very fast, even in cases where you have no wifi or mobile internet.
 90 2015-08-31 11:49:22 <hearn> mjerr: then the merchant can check it against their own local node and once they're satisfied it's valid, propagate it themselves with their own wired network connection
 91 2015-08-31 11:49:32 <mjerr> we are talking about lightning, right?
 92 2015-08-31 11:49:33 <mjerr> ;)
 93 2015-08-31 11:49:35 <hearn> no
 94 2015-08-31 11:49:38 <mjerr> oh, I was
 95 2015-08-31 11:49:50 <mjerr> from the very beginning, I'm just in it for lightning
 96 2015-08-31 11:50:02 <hearn> my mistake. carry on.
 97 2015-08-31 11:50:13 <hearn> you should probably take it to a #lightning channel though
 98 2015-08-31 11:51:22 <mjerr> yea, I'm over there aswell, but there isn't too much going on over there, and these issues aren't too 'lightning-technical-issues' as in most people don't need the grasp of the channel design and so forth
 99 2015-08-31 11:52:06 <mjerr> yea, as I said, if everyone would just connect to 5 local nodes, and I really love the idea the more I think about it, it would lead to 5+ hops for most payments, which would in turn easily take 1s+
100 2015-08-31 11:54:24 <hearn> you're just going to confuse people by talking about something that sounds superficially like bitcoin but isn't.
101 2015-08-31 11:55:20 <mjerr> I'm just trying to figure out, at which point the system becomes secure against governments.. having any kind of larger hubs might already lead to stuff like MSB registering
102 2015-08-31 12:01:39 <phantomcircuit> hearn, lightning is bitcoin
103 2015-08-31 12:01:44 <phantomcircuit> you of all people should know this
104 2015-08-31 12:02:08 <hearn> you believe that if you want to
105 2015-08-31 12:04:03 <phantomcircuit> hearn, so micropayment channels are not bitcoin?
106 2015-08-31 12:04:07 <mjerr> if we are thinking in node/client mode, that is people can participate just as basic clients - how many nodes do we need to make it impractical to orpress them? large companies will always have to comply...
107 2015-08-31 12:05:53 <mjerr> for me I am fine with accepting lightning isn't Bitcoin - doesn't mean it's not bitcoin though (case differentiation)
108 2015-08-31 12:05:55 <phantomcircuit> hearn, the silence is deafening
109 2015-08-31 12:06:08 <hearn> they're a way to temporarily move bitcoins off chain. whilst the coins are in such an arrangement you could argue they're some sort of "quasi bitcoin" because you can't spend them like you would normal coins. but such channels aren't meant to be used all that often, so having separate lingo for it is not really worth it
110 2015-08-31 12:06:18 <hearn> jesus, i was typing.
111 2015-08-31 12:06:43 <ratbanebo> boys boys
112 2015-08-31 12:08:51 <mjerr> phantomcircuit, do you think good latency can be achieved (let's stay non-privat, so no onion-routing for now) for lightning payments with 5+ hops?
113 2015-08-31 12:11:01 <phantomcircuit> mjerr, yes
114 2015-08-31 12:12:06 <mjerr> phantomcircuit, so for finalizing a payment between two nodes, you need 4 messages sent across them (txA, txB, revokeA, revokeB) - lets define a good latency around 1 second
115 2015-08-31 12:13:03 <mjerr> hm 50ms per message sounds reasonable - but this would not include additional routing efforts necessary for NAT/dynIp
116 2015-08-31 15:16:32 <wumpus> jonasschnelli: starting to like #6604 in the case of multiple clients / multiple servers
117 2015-08-31 15:23:35 <wumpus> not sure that's a common scenario for bitcoin, although maybe e.g. multiple wallets connecting to a node
118 2015-08-31 15:26:45 <wumpus> (although we don't really have a wallet that can work through RPC, e.g. like monero's simplewallet)
119 2015-08-31 15:27:59 <jonasschnelli> wumpus: #6604 could perform well when having multiple user/server, right.
120 2015-08-31 15:28:55 <jonasschnelli> wumpus: but i'm also not sure. It's just that the basic authentication feels wrong.
121 2015-08-31 15:29:14 <jonasschnelli> And i see the point that the asym. ec base pub key auth alone not solves the issues.
122 2015-08-31 15:36:15 <wumpus> right - e.g. the server itself is not authenticated
123 2015-08-31 15:40:57 <wumpus> so, sorry for me being very sceptical in that PR, I'm just wary of features that just 'feel' more secure if I don't understand the specific attack :)
124 2015-08-31 15:44:18 <jonasschnelli> wumpus: Totally okay. I have a thick skin, you can (and should) be as skeptical as you like with me. :)
125 2015-08-31 16:04:12 <wumpus> strange, my windows cross-compiles are hanging at "checking whether we are cross compiling... ". First the one of bitcoind, now libevent's
126 2015-08-31 16:05:46 <wumpus> "configure:3710: ./conftest.exe Err:process:__wine_kernel_init boot event wait timed out" hmm a wine issue
127 2015-08-31 16:07:37 <teward> are you building in Wine?
128 2015-08-31 16:07:40 <teward> or is this executing the exes :P
129 2015-08-31 16:08:32 <wumpus> no,I'm not building in wine, but apparantly it tries to execute an executable that it created
130 2015-08-31 16:15:57 <wumpus> ok, killing some wine-related background processes seems to have solved it
131 2015-08-31 16:28:48 <cfields> wumpus: much about wine+libevent is confusing. Once we've killed off any real bugs that it might've exposed (if any), I'm wondering if we should just add some config options specific to travis to allow for testing there without tainting real builds
132 2015-08-31 16:29:35 <wumpus> config options specific to testing .. hmm that sounds scary :)
133 2015-08-31 16:30:32 <cfields> wumpus: agreed. I'd really rather not sacrifice the ability to test against windows, though
134 2015-08-31 16:30:36 <wumpus> in that case it may be just as well to disable the testing on faux-window
135 2015-08-31 16:31:19 <wumpus> but yes, bitcoind should simply work in wine
136 2015-08-31 16:31:29 <wumpus> if it doesn't that means bitcoind should be fixed or wine
137 2015-08-31 16:31:51 <cfields> wumpus: one thing that i'm curious about is that the old rpc server doesn't have the same issues. Only way I can explain that is that boost must be setting the REUSE flag under wine
138 2015-08-31 16:34:57 <cfields> yep: acceptor->set_option(boost::asio::ip::tcp::acceptor::reuse_address(true));
139 2015-08-31 16:35:03 <wumpus> ouch, my cross compile fails on "configure: error: No working boost sleep implementation found".  "/usr/include/linux/errno.h:1:23: fatal error: asm/errno.h: No such file or directory"
140 2015-08-31 16:35:10 <wumpus> cfields: thanks
141 2015-08-31 16:35:29 <cfields> wumpus: with depends?
142 2015-08-31 16:36:11 <wumpus> cfields: yes :(
143 2015-08-31 16:36:17 <wumpus> freshly built
144 2015-08-31 16:36:32 <wumpus> "./configure --host=i686-w64-mingw32 --prefix=/home/orion/projects/bitcoin/bitcoin-win32/depends/i686-w64-mingw32 --disable-wallet"
145 2015-08-31 16:37:15 <cfields> wumpus: i'm using a freshly built one too. x86_64 though, but shouldn't make any difference...
146 2015-08-31 16:37:25 <cfields> not good that it's looking in /usr/include though
147 2015-08-31 16:37:53 <wumpus> oh wait, I've messed that part up
148 2015-08-31 16:39:11 <cfields> heh
149 2015-08-31 16:41:25 <wumpus> not the error I would have expected, but heh :)
150 2015-08-31 16:43:17 <cfields> wumpus: ok yea, looking through asio source, SO_REUSEADDR is used unconditionally. So at worst, we'd only be carrying forward any issues it causes
151 2015-08-31 16:43:52 <wumpus> cfields: right. Makes sense.
152 2015-08-31 16:44:42 <cfields> the only ways i can think of to actually fix it would be for wine to: 1. allow an env var to be set to specify that you want that runtime behavior, or 2. provide a wine-specific SO_REUSEADDR_WINE option
153 2015-08-31 16:44:49 <cfields> the second obviously being a massive hack
154 2015-08-31 16:47:56 <wumpus> yes... :/
155 2015-08-31 16:48:30 <wumpus> the problem is that wine doesn't interpret SO_REUSEADDR it as windows does, which would also be neigh impossible without OS level support
156 2015-08-31 16:48:44 <wumpus> I don't really see a solution to this. Let's keep working around it.
157 2015-08-31 16:49:24 <cfields> ok
158 2015-08-31 16:49:59 <cfields> note that it's probably possible to set the socket option manually on the listener rather than patching the libevent source. Would you prefer that?
159 2015-08-31 16:50:21 <Luke-Jr> isn't the obvious solution to fix WINE? O.o
160 2015-08-31 16:50:37 <Luke-Jr> or is that impractical for some reason?
161 2015-08-31 16:50:42 <cfields> Luke-Jr: there's not really a fix, in Windows the flag means something different
162 2015-08-31 16:51:01 <Luke-Jr> cfields: right, but WINE should interpret the flag the same way Windows does..
163 2015-08-31 16:51:15 <wumpus> yes, the obvious solution is to fix WINE. Not the *simple* solution, mind you.
164 2015-08-31 16:51:28 <wumpus> in any case it's not our problem
165 2015-08-31 16:51:59 <cfields> Luke-Jr: but in doing so, it would have to assume that the caller wanted that behavior. Basically it'd have to force the flag on for all Linux users whether they wanted it or not
166 2015-08-31 16:52:16 <wumpus> cfields: hmm. Yes that'd be possible too. Though I think this change belongs with libevent.
167 2015-08-31 16:52:29 <kanzure> hearn does wine development things, make him do it :-)
168 2015-08-31 16:52:57 <cfields> i linked a bug report where the wine devs discussed. They decided not to change the behavior
169 2015-08-31 16:53:04 <Luke-Jr> cfields: huh? if the caller is a Windows program, it wants Windows behaviour..?
170 2015-08-31 16:53:14 <Luke-Jr> linked where?
171 2015-08-31 16:53:20 <wumpus> that makes sense. it would be very hard to emulate windows' behavior on linux in this case.
172 2015-08-31 16:53:25 <wumpus> probably not worth it for the WINE team
173 2015-08-31 16:54:26 <cfields> Luke-Jr: https://bugs.winehq.org/show_bug.cgi?id=26031
174 2015-08-31 16:54:33 <kanzure> hearn_: heh
175 2015-08-31 16:54:41 <cfields> i think wumpus is ready to move on from the discussion though :)
176 2015-08-31 17:24:32 <wumpus> cfields: looks like we have another issue in -cli: we need to call WSAStartup, libevent somehow doesn't do that for us
177 2015-08-31 17:25:12 <wumpus> that's a pity, really, if the goal is to avoid platform speicific code
178 2015-08-31 17:25:27 <cfields> wumpus: aha, is that why we're not getting the disconnect before timeout?
179 2015-08-31 17:25:58 <wumpus> cfields: no, it doesn't make any difference in wine, just some warnings
180 2015-08-31 17:26:10 <wumpus> cfields: but on windows it'll probably cause serious issues
181 2015-08-31 17:26:46 <cfields> yea, good catch
182 2015-08-31 17:27:34 <wumpus> not being able to connect because the port is not open does give a different error on wine, so that rpctimeout doesn't work. Haven't found a link with rpctimeout yet.
183 2015-08-31 17:27:46 <wumpus> first rpctimeout=rpcwait
184 2015-08-31 17:28:02 <wumpus> -rpcwait looks simply ignored
185 2015-08-31 17:28:31 <wumpus> changing line 188 to throw CConnectionFailed("send http request failed"); instead of runtime_erro seems to solve that
186 2015-08-31 17:35:59 <wumpus> oh, crap, of course, util.cpp is not part of bitcoin-cli
187 2015-08-31 17:37:00 <wumpus> it is, never mind
188 2015-08-31 17:42:07 <wumpus> cfields: ok let's see how it goes https://github.com/laanwj/bitcoin/commit/50c19bce6412319d1beb655b2472c8948a798986  (yes, the CallRPC change and changing the timeout back don't belong in that commit, but it's just for testing :p)
189 2015-08-31 17:45:21 <cfields> wumpus: hmm, evhttp_make_request returns nonzero immediatly for you to indicate a connection failure? I thought i tried that
190 2015-08-31 17:46:29 <wumpus> cfields: yes, it's weird
191 2015-08-31 17:46:58 <cfields> wumpus: well, that's great as long as it works i guess :)
192 2015-08-31 17:48:29 <wumpus> seems it didn't
193 2015-08-31 17:49:07 <wumpus> oh something else is failing
194 2015-08-31 17:49:37 <wumpus> "Make: *** No rule to make target `hosts/.mk'.  Stop." what have I done
195 2015-08-31 17:51:32 <cfields> erm, that's a blank test config. looks like travis is acting up
196 2015-08-31 17:54:53 <jgarzik> evhttp_make_request returns non-zero immediately if connection initiation returns failure, yes (among other conditions)
197 2015-08-31 17:55:10 <jgarzik> e.g. if connect(2) fails immediately, without starting any async action in the kernel
198 2015-08-31 17:55:31 <wumpus> right, especially for localhost
199 2015-08-31 17:55:44 <jgarzik> can happen for parameters such as connecting to an IPv6 address on an IPv4-only host
200 2015-08-31 17:55:48 <jgarzik> yep
201 2015-08-31 18:01:27 <wumpus> cfields: ok, that didn't solve it, it's strange because here locally wine bitcoin-cli.exe -rpcwait is working fine
202 2015-08-31 18:01:59 <cfields> wumpus: even if you launch it before bitcoind?
203 2015-08-31 18:02:10 <wumpus> cfields: yes, I didn't try the other way around
204 2015-08-31 18:03:34 <cfields> wumpus: seems travis ran fine?
205 2015-08-31 18:03:43 <cfields> (other than the weirdness)
206 2015-08-31 18:04:26 <cfields> whoops, sorry, looking at the wrong PR
207 2015-08-31 18:05:14 <wumpus> well, will look at it again tomorrow, giving up for today
208 2015-08-31 18:06:59 <wumpus> huh I get "win tests currently disabled" when I try to launch rpc-tests.sh locally
209 2015-08-31 18:07:20 <wumpus> commenting that out...
210 2015-08-31 18:08:29 <cfields> wumpus: rebase to master, that was removed a few days ago
211 2015-08-31 18:08:42 <wumpus> right
212 2015-08-31 18:10:39 <wumpus> maybe that will introduce the issue locally too (though unlikely)
213 2015-08-31 18:16:52 <wumpus> yes, windows RPC tests fail locally too, albeit with a different error "JSONRPC error: Error: Keypool ran out, please call keypoolrefill first"
214 2015-08-31 18:22:00 <wumpus> ok that was a misconfiguration (--enable-wallet)
215 2015-08-31 19:48:07 <b-itcoinssg> What is the reasoning behind duplicating a leaf of an odd number merkle tree, instead of using the odd number leaf as a separate branch to build the merkle tree?