1 2017-10-11 10:18:32 <maks25> Hi! I’m confused about the inner workings of bitcoin. As far as I understand: Transactions are chained together by hashing the PublicKey(of the Receiver) and the previous transaction, and then signing it with the PrivateKey(of the Sender). My question is, does each transaction also include the unhashed data? If not, how do we know how many coins are being transferred since all the values are hashed?
  2 2017-10-11 10:26:32 <matsjj> e valid?)
  3 2017-10-11 10:26:32 <matsjj> Hello, I'm currently working on replay protection. I was always under the impression that a defined SIGHASH type is consensus-critical. Reading the code (and getting some feedback from apoelstra), it seems like SIGHASH_ALL is the default, and any value thats not SIGHASH_SINGLE/SIGHASH_NONE will implicitly default to SIGHASH_ALL. (Bonus: Wouldn't this allow a miner to change txhash of all signatures, since any SIGHASH would b
  4 2017-10-11 10:30:50 <arubi> matsjj, the sighash type are 4 bytes that are signed as part of the whole sighash
  5 2017-10-11 10:31:18 <arubi> the relayed tx has only one byte sighash type in it.  if it's unknown, it's treated as ALL afaik
  6 2017-10-11 10:31:34 <arubi> but still changing it around (or the other 3 bytes that aren't relayed) is invaliding the sig
  7 2017-10-11 10:31:53 <arubi> the cleanest replay protection is flipping a sighash type bit that is >7
  8 2017-10-11 10:32:26 <arubi> that way you can both keep the ALL, NONE, etc.  stuff the same, and not risk replays defaulting to ALL
  9 2017-10-11 10:32:46 <arubi> (since there is no way for the other fork to know about the flipped bit at bit >7)
 10 2017-10-11 10:33:32 <matsjj> I see! Yea this makes sense, otherwise anyone could just change it to SIGHASH_NONE and change the outputs
 11 2017-10-11 10:33:59 <matsjj> Thanks, very helpful!
 12 2017-10-11 10:34:02 <arubi> yw
 13 2017-10-11 10:37:12 <arubi> maks25, can you rephrase?  what unsigned data?
 14 2017-10-11 10:37:22 <arubi> err, unhashed data
 15 2017-10-11 10:41:06 <maks25> arubi: I’m just a bit confused about what data is contained within a transaction that miners need in order to verify it. After reading the nakamoto whitepaper I was under the impression that the transaction data within a block is all hashed, wondering if it also contains unhashed data on the transactions.
 16 2017-10-11 10:41:48 <arubi> a transaction appears in full
 17 2017-10-11 10:42:19 <maks25> arubi: great
 18 2017-10-11 10:42:20 <arubi> it contains the hash of the input transaction that it's spending, so to validate it you'll have to look at that previous input
 19 2017-10-11 10:42:35 <maks25> arubi: that makes sense
 20 2017-10-11 10:44:34 <esotericnonsense> maks25: consider also that the encoding of the block doesn't matter all that much providing you have the data to back it
 21 2017-10-11 10:44:52 <esotericnonsense> maks25: i'd have to read up to refresh my memory, but i believe compact block transfer essentially uses that
 22 2017-10-11 10:45:39 <esotericnonsense> maks25: e.g. if you already have a bunch of transactions that exist in a new block you see, then you don't need to redownload them all, you just need the hashes included in that block (if you already have all the transactions in your mempool)
 23 2017-10-11 10:46:02 <esotericnonsense> (and the ordering of the hashes)
 24 2017-10-11 10:46:22 <maks25> esotericnonsense: Yea that makes sense given that you can validate them just by their hashes
 25 2017-10-11 10:46:59 <esotericnonsense> well no, you need the full transaction to validate the tx, but if you have a prevalidated tx you just need to know whether or not it is included in the merkle tree and where
 26 2017-10-11 10:56:55 <maks25> esotericnonsense: And then just check that the Merkle root matches the one in the block..am I getting that right?
 27 2017-10-11 11:19:53 <esotericnonsense> yeah
 28 2017-10-11 11:20:31 <esotericnonsense> for example if I know that you already have all transactions I can just send you the block header plus the ordering of the leaves (hashes) in the merkle tree
 29 2017-10-11 11:20:39 <esotericnonsense> and from that you can construct a block
 30 2017-10-11 11:21:08 <esotericnonsense> well, I'd have to send you the coinbase tx (because you probably wouldn't have that), and any transactions that the miner knew about that you didn't
 31 2017-10-11 11:33:28 <maks25> esotericnonsense: any in-depth readings you would recommend?
 32 2017-10-11 11:34:12 <maks25> I’ve probably spent over a week on researching Bitcoin and also Ethereum, but the majority of the stuff I am finding is very broad. (I did read both the white papers though)
 33 2017-10-11 12:54:35 <CadelLeeStormer> I have a small question regarding nLockTime transactions... If for example today i create such a transaction that cannot be accepted into a block before a year. If i propagate it now to the network. Would it be dropped by nodes or kept by them ?
 34 2017-10-11 12:57:19 <GAit> CadelLeeStormer: it won't propagate or even be accepted by your own node
 35 2017-10-11 13:01:20 <CadelLeeStormer> Thanks.
 36 2017-10-11 14:20:34 <ghost43> do minikeys have compressed or uncompressed pubkeys? or is it ambiguous?
 37 2017-10-11 14:58:34 <wxss> ghost43: AFAICT the only specification I can find (https://en.bitcoin.it/wiki/Mini_private_key_format) doesn't mention that. It only defines how you derive the minikey from a private key.
 38 2017-10-11 14:59:05 <ghost43> great....... :P thanks
 39 2017-10-11 14:59:08 <wxss> You can then use that private key to either create a compressed or uncompressed pubkey
 40 2017-10-11 14:59:47 <wxss> Buit maybe someone else knows about a better (more complete) specification of minikeys
 41 2017-10-11 15:00:41 <ghost43> well obviously. you can create all kinds of scriptPubKeys and addresses from a private key. but apps can't be expected to look up and monitor all of them. one could use a minikey to create a native p2wpkh address..
 42 2017-10-11 15:01:14 <wxss> exactly, so the specification is incomplete.
 43 2017-10-11 15:36:12 <matsjj> @arubi Out of curiousity - does that mean Bitcoin Cash is just policy protected? It looks like they just used a different SIGHASH, without changing any of the other bits when preparing the SignatureHash?
 44 2017-10-11 15:36:14 <matsjj> See https://github.com/Bitcoin-ABC/bitcoin-abc/blob/d46be71cdae64b50207a78b2804968f919cac408/src/script/interpreter.h#L26
 45 2017-10-11 15:38:28 <arubi> matsjj, they changed the entire signature scheme.  they're using bip143 for all transactions, and don't have segwit scriptpubkeys at all
 46 2017-10-11 15:38:54 <arubi> so even if the client could parse and try to check the sig, it would still be way wrong because the incorrect scheme is applied
 47 2017-10-11 15:39:43 <matsjj> Ah I see, I guess there are no segwit outputs that could be consumed that way in their chain
 48 2017-10-11 15:40:23 <arubi> you could send to a segwit program, but that would just be anyone-can-spend script with no further soft fork rules for checksigs
 49 2017-10-11 15:44:04 <arubi> matsjj, one comment I wanted to make on your PR, now with segwit live, there's a weird edge case that can happen when only using sighash bytes for replay protection
 50 2017-10-11 15:45:34 <arubi> say I have funds in a segwit output A, I can create a replay protected tx to B on the s2x chain, then after a while create a sighash ALL tx from the same A to the same B on the bitcoin chain and still retain the same txid
 51 2017-10-11 15:46:56 <arubi> this isn't actually replay, but might cause problems for services
 52 2017-10-11 15:47:07 <matsjj> Oh of course! It is indeed an edge case, as the transaction on the bitcoin chain would need the new sighash too (which is non-standard)
 53 2017-10-11 15:47:16 <matsjj> But an interesting one
 54 2017-10-11 15:47:25 <arubi> no what I mean s
 55 2017-10-11 15:47:26 <arubi> is*
 56 2017-10-11 15:47:51 <matsjj> Oh you are right, since the signature (and sighash type) is no longer part of the txhash
 57 2017-10-11 15:47:53 <arubi> it's because signatures are not part of the txid anymore.  for non segwit outputs this isn't true because a different bit in the first byte will change the txid
 58 2017-10-11 15:47:58 <arubi> right
 59 2017-10-11 15:48:23 <matsjj> So while there is no risk of replay YET, they also cannot be considered _split_ yet.
 60 2017-10-11 15:48:51 <arubi> yea it's a very weird state.  essentially the same transaction
 61 2017-10-11 15:48:56 <matsjj> Since the exact same outputs live on both chains
 62 2017-10-11 15:49:27 <arubi> the only clean place to flip another bit is the transaction version
 63 2017-10-11 15:49:39 <arubi> but it has to be one of the invalid bits else I can still do that on both chains
 64 2017-10-11 15:50:10 <matsjj> Funny. Thats certainly something to keep in mind when it comes to writing an actual specification for this, for who ever wants to build on top of this.
 65 2017-10-11 15:50:18 <matsjj> I was looking into that too - which bits are actually invalid?
 66 2017-10-11 15:50:43 <arubi> hmm, good question, my guess is anything which will make it negative (if it can be even heh)
 67 2017-10-11 15:51:00 <arubi> but there's got to be such a bit
 68 2017-10-11 16:07:59 <arubi> matsjj, s/the only place/the only other place/
 69 2017-10-11 16:08:19 <arubi> because really if you flip an invalid bit in the version, then you're done.  no need for elaborate sighash bytes anymore
 70 2017-10-11 16:21:33 <grubles> i'm going to take another stab at gitian building
 71 2017-10-11 16:21:40 <grubles> this time with virtualbox
 72 2017-10-11 16:21:50 <arubi> what did you try before?  lxc right?
 73 2017-10-11 16:22:22 <grubles> yeah
 74 2017-10-11 16:23:14 <arubi> was looking into the docker thing in the gitian doc, but seems like it's from 2015, using debian wheezy.. probably too old for current builds
 75 2017-10-11 16:26:38 <grubles> yeah i've tried using docker previously too
 76 2017-10-11 16:26:42 <grubles> a few months ago
 77 2017-10-11 16:26:51 <grubles> the virtualbox guide uses wheezy too
 78 2017-10-11 16:26:53 <grubles> er no
 79 2017-10-11 16:26:54 <grubles> jessie
 80 2017-10-11 16:34:58 <grubles> wait i think the virtualbox route uses lxc too...
 81 2017-10-11 16:35:08 <arubi> probably eventually
 82 2017-10-11 16:45:42 <matsjj> arubi: I'm not sure wrt nVersion. in bitcoinJ and BitcoinJS it's deserialising an UNsigned 32bit, while the bitcoin wiki states that this is a signed 32bit.
 83 2017-10-11 16:47:29 <matsjj> Also I think if we are to mess with it in a way that bitcoin-core sees it as invalid, there's a fair chance other receiving wallets would perceive it as broken too. That was the _good_ part about using SigHash, as lite clients normally don't look at the signature.
 84 2017-10-11 16:48:12 <wumpus> in bitcoin core nVersion is signed
 85 2017-10-11 16:48:15 <arubi> there's no other way that I can think of to fix the edge case when segwit is active
 86 2017-10-11 16:50:26 <matsjj> wumpus, oh, byte representations are the same until the last bit. So flipping the topmost bit would render the transaction invalid in bitcoin-core, is that correct?
 87 2017-10-11 17:05:38 <matsjj> Ah doesn't look like this is actually enforced anywhere
 88 2017-10-11 17:06:55 <arubi> matsjj, I'm pretty sure that a negative version is invalid
 89 2017-10-11 17:21:01 <phantomcircuit> arubi, they're not
 90 2017-10-11 17:21:05 <phantomcircuit> just non-standard
 91 2017-10-11 17:21:09 <matsjj> arubi, so far I've only found that negative block numbers are disallowed (since BIP 34)
 92 2017-10-11 17:21:25 <phantomcircuit> there's transactions with negative versions in the chain
 93 2017-10-11 17:21:43 <arubi> oh really, that's a good bit of trivia
 94 2017-10-11 17:23:37 <matsjj> Ah indeed. https://blockchain.info/rawtx/35e79ee733fad376e76d16d1f10088273c2f4c2eaba1374a837378a88e530005 if you ever need to prove it to someone
 95 2017-10-11 17:24:29 <arubi> not bad :)
 96 2017-10-11 17:46:14 <grubles> ok yeah there's definitely something up with my networking
 97 2017-10-11 17:46:28 <grubles> because there is a -dev discussion from 2015 about the same issue
 98 2017-10-11 17:46:29 <arubi> it's dns isn't it
 99 2017-10-11 17:47:15 <grubles> not sure
100 2017-10-11 17:47:25 <grubles> i can ping 10.0.2.2 from the gitian-builder VM
101 2017-10-11 17:47:58 <arubi> so it's just that apt-cacher-ng isn't running there
102 2017-10-11 17:48:01 <grubles> of course the logs end prematurely
103 2017-10-11 17:48:08 <arubi> at that destination that is
104 2017-10-11 17:49:14 <grubles> it seems
105 2017-10-11 17:49:19 <grubles> that should be running on the host, right?
106 2017-10-11 17:49:59 <arubi> whatever host has the interface with the 10.0.2.2 ip
107 2017-10-11 17:50:40 <arubi> usually it's something that runs on its own container
108 2017-10-11 17:51:04 <arubi> but I'm not sure about how gitian expects it
109 2017-10-11 17:52:12 <grubles> i would assume the gitian host runs the cacher
110 2017-10-11 17:52:20 <grubles> and the container connects to the host
111 2017-10-11 17:52:56 <arubi> where can you pint 10.0.2.2 from?
112 2017-10-11 17:52:59 <arubi> s/ping
113 2017-10-11 17:53:08 <grubles> the debian gitian host
114 2017-10-11 17:53:31 <arubi> ah, and does `sudo ifconfig -a` says something about an interface with that ip?
115 2017-10-11 17:54:15 <grubles> nope
116 2017-10-11 17:54:32 <grubles> br0 is on 10.0.3.2
117 2017-10-11 17:54:36 <grubles> eth0 is on 10.0.2.15
118 2017-10-11 17:55:23 <grubles> so i'm not even sure what has 10.0.2.2 ....
119 2017-10-11 17:55:44 <arubi> can you try `sudo netstat -tulpan | grep '10.0.2.2'`
120 2017-10-11 17:56:06 <arubi> ssh into it?  see if it accepts the same credentials as the host..
121 2017-10-11 17:56:32 <grubles> ah i can ssh in
122 2017-10-11 17:56:39 <arubi> hostname?
123 2017-10-11 17:56:52 <grubles> "debian"
124 2017-10-11 17:56:59 <grubles> same as host
125 2017-10-11 17:57:07 <arubi> `which apt-cacher-ng` returns anything?
126 2017-10-11 17:57:16 <grubles> no
127 2017-10-11 17:57:26 <arubi> try the netstat again from within the ssh
128 2017-10-11 17:57:53 <arubi> or I guess the ifconfig will return the same output if it's the same system
129 2017-10-11 17:58:11 <arubi> lots of ways to know, create a file in /tmp :)
130 2017-10-11 17:58:21 <grubles> yeah same ifconfig output
131 2017-10-11 17:58:55 <arubi> alright, you could try to install and run apt-cacher-ng on the host then, or make it route 10.0.2.2 to some debian mirror maybe?
132 2017-10-11 17:59:36 <grubles> hm it's already installed
133 2017-10-11 17:59:53 <arubi> huh, so just not in your path
134 2017-10-11 18:00:02 <arubi> `sudo which apt-cacher-ng` ?
135 2017-10-11 18:00:15 <arubi> or `sudo /etc/init.d/apt-cacher-ng status`
136 2017-10-11 18:00:16 <grubles> /usr/sbin/apt-cacher-ng
137 2017-10-11 18:00:22 <grubles> ah yea
138 2017-10-11 18:00:31 <arubi> `sudo /etc/init.d/apt-cacher-ng start` probably :)
139 2017-10-11 18:00:37 <grubles> it's running
140 2017-10-11 18:01:14 <arubi> I'm trying to remember if there was some stuff I had to do to make it run (was unrelated..)
141 2017-10-11 18:01:41 <arubi> I can't remember anything specific.  iirc it was upping a container with the service running, then other containers just fetch stuff from it
142 2017-10-11 18:02:07 <arubi> can you `apt-get update` on the host without errors?
143 2017-10-11 18:02:40 <grubles> maybe i have to specify which address to bind to in /etc/apt-cacher-ng/acng.conf
144 2017-10-11 18:02:55 <grubles> yea apt-get update works
145 2017-10-11 18:03:17 <arubi> it looks like binding to the address is correct, the guest expects this ip
146 2017-10-11 18:04:29 <arubi> some elaborate test you can try is to point your host's sources.list file to your own apt-cacher-ng's ip and try to apt-get update again
147 2017-10-11 18:04:45 <arubi> if that succeeds, then the service is running correctly at least
148 2017-10-11 18:11:55 <grubles> hm couldn't bind to socket: cannot ssign requested address
149 2017-10-11 18:11:58 <grubles> assign, rather
150 2017-10-11 18:12:24 <arubi> where's that from?
151 2017-10-11 18:12:48 <grubles> /etc/init.d/apt-cacher-ng status
152 2017-10-11 18:15:07 <grubles> after i added BindAddress: localhost 10.0.2.2 to acng.conf
153 2017-10-11 18:17:30 <arubi> did you restart it first?
154 2017-10-11 18:17:48 <grubles> yes
155 2017-10-11 18:18:16 <arubi> wait why call that address localhost?
156 2017-10-11 18:18:23 <arubi> call it debian or whatever
157 2017-10-11 18:18:35 <arubi> localhost is 127.x.x.x stuff
158 2017-10-11 18:19:21 <arubi> did you try the netstat command before you edited acng.conf actually?
159 2017-10-11 18:19:39 <arubi> I'm interested if it was already running there or not.  something did respond to ping
160 2017-10-11 18:21:28 <grubles> doesn't seem to be running when ssh'd into 10.0.2.2
161 2017-10-11 18:21:31 <grubles> based on the netstat
162 2017-10-11 18:23:21 <arubi> netstat just shows port 22 then?
163 2017-10-11 18:23:37 <grubles> yeah 22 and 22222
164 2017-10-11 18:24:16 <arubi> okay, can you revert what you did on acng.conf and instead try to set your host's 'sources.list' file to fetch from 10.0.2.2 ?
165 2017-10-11 18:24:30 <arubi> (and restart -ng so it's running again)
166 2017-10-11 18:25:09 <grubles> still unable to connect
167 2017-10-11 18:25:32 <arubi> oh so it wasn't running before either then?
168 2017-10-11 18:26:07 <grubles> /etc/init.d/apt-cacher-ng status shows that it's running
169 2017-10-11 18:28:14 <arubi> and pointing your host's sources.list to 10.0.2.2 now fails apt-get update?
170 2017-10-11 18:29:08 <grubles> right
171 2017-10-11 18:30:40 <arubi> does the apt-cacher service have a log file in /var/log maybe?
172 2017-10-11 18:30:49 <arubi> or probably it's documented somewhere
173 2017-10-11 18:32:05 <grubles> yeah in /var/log/apt-cacher-ng/apt-cacher.log
174 2017-10-11 18:32:27 <grubles> looks like it's cached the ubuntu packages
175 2017-10-11 18:32:32 <grubles> from the base-vm
176 2017-10-11 18:33:46 <arubi> which port is it supposed to be running on?
177 2017-10-11 18:33:58 <arubi> try `netstat -tulpan | grep <port>`..
178 2017-10-11 18:34:09 <grubles> 3142
179 2017-10-11 18:34:34 <grubles> looks like it's bound to 0.0.0.0
180 2017-10-11 18:34:38 <grubles> hm
181 2017-10-11 18:34:40 <arubi> great..
182 2017-10-11 18:35:20 <arubi> try to set your sources.list to localhost instead of that ip and update
183 2017-10-11 18:36:39 <arubi> maybe something is routing 10.0.2.2 to localhost for some traffic but not all?  very weird
184 2017-10-11 18:37:01 <grubles> yeah i can't find any documentation on it
185 2017-10-11 18:37:08 <grubles> setting to localhost fails to
186 2017-10-11 18:37:44 <arubi> does `netcat 10.0.2.2 3142` connect at all?
187 2017-10-11 18:38:33 <grubles> no
188 2017-10-11 18:38:54 <arubi> do you have the pid of the process bound to 0.0.0.0 on that port?
189 2017-10-11 18:39:02 <arubi> should be on that netstat line
190 2017-10-11 18:39:10 <grubles> 20463
191 2017-10-11 18:39:29 <arubi> `sudo kill -15 20463`
192 2017-10-11 18:39:55 <arubi> then `ps -p 20463` , see that it's gone
193 2017-10-11 18:40:20 <grubles> ok it's kliled
194 2017-10-11 18:40:23 <grubles> killed, rather
195 2017-10-11 18:40:30 <arubi> alright, try to sudo restart cacher-ng again
196 2017-10-11 18:40:41 <arubi> (clean .conf)
197 2017-10-11 18:41:03 <grubles> ok done
198 2017-10-11 18:41:18 <arubi> okay, netcat to 10.0.2.2 and its port, see if it connects
199 2017-10-11 18:41:56 <grubles> nope
200 2017-10-11 18:42:21 <arubi> so it's just "connection refused" ?
201 2017-10-11 18:42:31 <grubles> correct
202 2017-10-11 18:42:58 <arubi> and I bet netstat shows it running and bound to 0.0.0.0 ?
203 2017-10-11 18:43:50 <grubles> yep!
204 2017-10-11 18:44:47 <arubi> I think we need to call a scientist
205 2017-10-11 18:44:57 <grubles> haha
206 2017-10-11 18:47:04 <bugs_> what about firewall
207 2017-10-11 18:53:31 <arubi> on the host VM?
208 2017-10-11 18:54:23 <arubi> if it's anything, it's between the host VM and the metal host.  I don't know much about qubes os
209 2017-10-11 18:55:53 <grubles> oh this isn't on qubes
210 2017-10-11 18:56:04 <grubles> it's on vanilla fedora 26
211 2017-10-11 18:56:43 <grubles> i figured there was some esoteric VM separation mechanism in qubes
212 2017-10-11 18:57:12 <grubles> well...of course there is...but i mean specifically for networking in this context
213 2017-10-11 18:59:33 <arubi> can you try, stop the apt-cacher service, then try to ssh from the host vm into 10.0.2.2 again
214 2017-10-11 19:00:10 <arubi> see if if 10.0.2.2 is the cacher's thing or some actual interface
215 2017-10-11 19:00:37 <Sentineo> maybe you need to use a netns? :)
216 2017-10-11 19:01:05 <grubles> ssh still works
217 2017-10-11 19:01:54 <arubi> maybe now you can create an ssh tunnel from 10.0.2.2:3142 to a debian repo's ip and port..
218 2017-10-11 19:02:15 <arubi> then when the guest tries it, it'll just be redirected?  it's all so weird :)
219 2017-10-11 19:02:32 <arubi> Sentineo, I guess he could if you could write the gitian docs for it :P
220 2017-10-11 19:03:22 <arubi> it's so weird, it's running, it's on the correct port, it's listening to all interfaces..
221 2017-10-11 19:04:03 <grubles> where is it even specified to use the apt-cacher instead of just the actual repos
222 2017-10-11 19:04:08 <Sentineo> I am too lazy to scroll up what it is all about :)
223 2017-10-11 19:04:09 <grubles> and why
224 2017-10-11 19:04:17 <Sentineo> but sounds like a vm thing, container routing issue
225 2017-10-11 19:05:19 <arubi> probably so you could easily fix versions without them disappearing from the actual repos
226 2017-10-11 19:05:32 <grubles> makes sense
227 2017-10-11 19:06:26 <arubi> is your network capable of ipv6 stuff?  mine isn't and I always disable it everywhere as a habit
228 2017-10-11 19:06:45 <arubi> (specifically apt-get often fails on new vms and stuff)
229 2017-10-11 19:06:48 <grubles> my local net is
230 2017-10-11 19:06:54 <grubles> but not supported by my isp
231 2017-10-11 19:07:15 <arubi> hm
232 2017-10-11 19:07:32 <Sentineo> u use 6to4?
233 2017-10-11 19:07:37 <arubi> oh no no
234 2017-10-11 19:07:40 <grubles> no
235 2017-10-11 19:07:53 <Sentineo> then turn it off on your local net
236 2017-10-11 19:08:10 <arubi> did cacher-ng listen on ipv6 also on that netstat stuff?
237 2017-10-11 19:08:14 <Sentineo> router advertisements triger that shit automatically :)
238 2017-10-11 19:10:50 <grubles> arubi, yea
239 2017-10-11 19:11:07 <arubi> probably best to turn it all off then, disable ipv6 on the host vm
240 2017-10-11 19:13:01 <arubi> also on acng.conf :
241 2017-10-11 19:13:02 <arubi> # information, i.e. under http://localhost:3142/acng-report.html
242 2017-10-11 19:13:02 <arubi> ReportPage: admin
243 2017-10-11 19:13:02 <arubi> Virtual page accessible in a web browser to see statistics and status
244 2017-10-11 19:13:20 <arubi> might be worth to check if that's reachable at all in a browser from the host vm
245 2017-10-11 19:22:15 <grubles> i gotta run for a bit
246 2017-10-11 19:22:30 <arubi> no worries
247 2017-10-11 20:32:36 <grubles> ok yeah let's see if i can get the report page
248 2017-10-11 20:35:06 <grubles> i can curl http://localhost:3142 from the host
249 2017-10-11 20:40:59 <grubles> it's.......seemingly working now
250 2017-10-11 20:41:08 <grubles> wtf
251 2017-10-11 20:41:37 <grubles> (it being the build script)
252 2017-10-11 20:57:01 <arubi> hah, weird.