1 2017-10-08 00:28:13 <esotericnonsense> i'm trying to understand https://en.bitcoin.it/wiki/OP_CHECKSIG
  2 2017-10-08 00:29:17 <esotericnonsense> etotheipi's diagram seems pretty comprehensive but i'm confused with the OP_CODESEPERATOR stuff. in a 'standard' p2pkh case would SCRIPT_PART{1, 2, 4} just not exist
  3 2017-10-08 00:30:43 <esotericnonsense> I can check this by just writing the code and trying to get a sig to verify, but I have no (present) need for that so it's a bit of an endeavour
  4 2017-10-08 00:36:26 <esotericnonsense> checksig is a crazy op, I see what people mean about calling it 'OP_DO_BITCOIN'
  5 2017-10-08 04:17:37 <arubi> esotericnonsense, luckily segwit fixes the crazy :)
  6 2017-10-08 04:20:53 <arubi> you're correct that standard stuff don't use codesep.  it's not very useful anyway unless you really wanna have two different sighashes in the same script
  7 2017-10-08 14:37:07 <esotericnonsense> yeah i guess i'm trying to figure out where exactly the script comes from in 'Step 4' because it seems a bit arbitrary to me
  8 2017-10-08 14:37:34 <esotericnonsense> 'create subscript from last OP_CODESEP to end of script' in that example, i don't see how you wouldn't just have SCRIPT_PART4
  9 2017-10-08 14:37:42 <esotericnonsense> (for the subscript)
 10 2017-10-08 14:40:23 <esotericnonsense> either i'm misinterpreting Step 2, or it's just wrong
 11 2017-10-08 14:45:24 <esotericnonsense> aside from that I'd be interested to know why Step 8 is even done (obviously it's 'just the way OP_CHECKSIG works', but a justification for it, does it prevent an attack of some sort, is it only useful in conjunction with some OP_CODESEP stuff)
 12 2017-10-08 14:46:38 <arubi> script in part 4 comes from PrevTx.PkScript
 13 2017-10-08 14:47:01 <arubi> it's the subscript made out of the last executed codesep and onwards
 14 2017-10-08 14:47:15 <esotericnonsense> ah, that's the crucial bit
 15 2017-10-08 14:47:18 <esotericnonsense> last _executed_ codesep
 16 2017-10-08 14:47:19 <arubi> (without the remaining codeseps)
 17 2017-10-08 14:49:32 <esotericnonsense> yeah that makes sense to me now. it's just that I was thinking 'last codesep (i.e. third one in that diagram)' rather than 'last executed codesep (second one in that diag)'
 18 2017-10-08 14:51:00 <arubi> step 8 is..  codeseps are pretty much useless right now in bitcoin (I've seen maybe one good use).  the idea with checksig only covering a part of the executed script (by using codeseps to separate the areas a checksig covers) is a very cool idea, but it doesn't really work because you always sign the prevtxs' txid in the input
 19 2017-10-08 14:51:35 <arubi> and that prevtx had the whole scriptpubkey in it (in the output itself)
 20 2017-10-08 14:51:46 <arubi> so you always sign a hash of the entire script anyway
 21 2017-10-08 14:52:43 <arubi> if you didn't have to sign an input txid, you could do lots of interesting things, but alas :)
 22 2017-10-08 14:52:48 <esotericnonsense> yeah
 23 2017-10-08 14:53:15 <esotericnonsense> thanks arubi
 24 2017-10-08 14:53:21 <arubi> yw
 25 2017-10-08 15:00:23 <grubles> so i'm getting some errors running the automated gitian builder script
 26 2017-10-08 15:01:52 <grubles> https://0bin.net/paste/JJ3XkfNiWqjGpgvw#SGNCITeDC6vclWkFdirVZYfpJ1JGPIBjPRZo12zj4eS
 27 2017-10-08 15:09:20 <arubi> is that the file install.log?  seems like apt-get failed?
 28 2017-10-08 15:09:47 <grubles> no that's just the stdout that the script printed out
 29 2017-10-08 15:10:41 <arubi> not sure, I never tried the gitian build but fwiw it seems it failed with `apt-get update`
 30 2017-10-08 15:11:15 <arubi> maybe if you can get that file with the output, looks like it's writing to 'var/install.log' but I don't know if it's on the host or guest
 31 2017-10-08 15:19:19 <grubles> hm
 32 2017-10-08 15:23:55 <grubles> lxc-ls shows no containers
 33 2017-10-08 15:24:43 <grubles> and install.log does not exist on the host
 34 2017-10-08 15:28:38 <arubi> there was a time when apt-get'ing from ubuntu repositories was flaky.  sometimes it would hang for a long time before it starts downloading, sometimes it'd even just time out.  I'm guessing it was geolocation related and some mirrors just sucked.  maybe related..  the install.log file will have more info.  if you can make gitian to `cat` that file, maybe the output will pass to the log you can see
 35 2017-10-08 15:45:33 <grubles> my guess is it's something qubes os related
 36 2017-10-08 15:47:15 <esotericnonsense> the upstart errors look interesting, i haven't used gitian, do those come up normally
 37 2017-10-08 17:11:50 <grubles> esotericnonsense, not sure
 38 2017-10-08 17:12:26 <grubles> arubi, when building the base vm image it is able to download all of the needed packages
 39 2017-10-08 17:12:54 <grubles> harumph
 40 2017-10-08 17:13:17 <arubi> grubles, my second guess is that the ubuntu image uses ipv6 and routing network out of the container somehow fails for ipv6
 41 2017-10-08 17:13:37 <arubi> I had that happen locally with ubuntu VMs, unrelated to gitian, so maybe that's it..
 42 2017-10-08 17:14:42 <arubi> the ubuntu image I used in a VM tried to reach the repositories on an ipv6 address, but nothing I use supports it
 43 2017-10-08 17:14:42 <grubles> maybe
 44 2017-10-08 17:16:15 <grubles> which image did you use
 45 2017-10-08 17:16:29 <arubi> it was 16.04.03
 46 2017-10-08 17:17:17 <grubles> i'm using trusty
 47 2017-10-08 17:17:26 <grubles> which is...14.04 i think?
 48 2017-10-08 17:18:04 <arubi> oh, it might do that too..  don't know
 49 2017-10-08 17:18:41 <grubles> oh wait
 50 2017-10-08 17:18:48 <grubles> i wiped and started from scrach
 51 2017-10-08 17:18:52 <grubles> scratch rather
 52 2017-10-08 17:19:27 <grubles> the build script can't locate python-vm-builder
 53 2017-10-08 17:19:30 <grubles> but i installed it...
 54 2017-10-08 17:19:34 <arubi> hm
 55 2017-10-08 17:23:23 <grubles> oh that's just the script attempting to apt-get it
 56 2017-10-08 17:58:08 <grubles> hm same error
 57 2017-10-08 17:59:21 <arubi> grubles, my IT experience says "it's DNS"
 58 2017-10-08 18:02:58 <grubles> yeah could be
 59 2017-10-08 18:05:02 <esotericnonsense> it's always DNS
 60 2017-10-08 18:05:56 <arubi> every. time.
 61 2017-10-08 18:06:09 <grubles> lol
 62 2017-10-08 18:06:29 <grubles> i'm not familiar enough with lxc to test if that's the issue
 63 2017-10-08 18:07:08 <arubi> if you can make it ping something like www.google.com then you'll know if it can resolve it or not
 64 2017-10-08 18:07:22 <esotericnonsense> right or just dig inside the container
 65 2017-10-08 18:07:31 <arubi> but if you can do that, it's better to just make it `cat /path/to/install.log`
 66 2017-10-08 18:07:35 <grubles> well that's the thing
 67 2017-10-08 18:07:42 <grubles> it's like it doesn't create the container
 68 2017-10-08 18:07:45 <grubles> lxc-ls shows nothing
 69 2017-10-08 18:07:53 <esotericnonsense> grubles: lxc-ls -f? (is it -f?)
 70 2017-10-08 18:08:01 <esotericnonsense> to show all containers started or otherwise
 71 2017-10-08 18:08:03 <grubles> -f shows nothing as well
 72 2017-10-08 18:08:06 <esotericnonsense> it's been a while since I played with lxc
 73 2017-10-08 18:08:11 <esotericnonsense> hm
 74 2017-10-08 18:08:14 <arubi> maybe it terminates if the container ends up with an error?
 75 2017-10-08 18:09:50 <arubi> I don't know how lxc works in depth, I use lxc in qemu but it's all abstracted with beautiful gui.  dockers do that though, if one of the steps it's doing at setup errors, it just terminates
 76 2017-10-08 18:09:59 <arubi> er, in proxmox*
 77 2017-10-08 18:10:07 <grubles> terminates as in deletes?
 78 2017-10-08 18:10:12 <grubles> or otherwise is removed
 79 2017-10-08 18:10:24 <esotericnonsense> there's a place where your lxc config lives, filesystems exist, etc
 80 2017-10-08 18:10:30 <esotericnonsense> probably /var/lib/lxc or something like that
 81 2017-10-08 18:10:54 <arubi> for the dockers the intermediate states are kept
 82 2017-10-08 18:10:57 <esotericnonsense> if you have a container name or any useful string or whatever you could just `find / -name="thing"` on the root fs
 83 2017-10-08 18:11:23 <grubles> /var/lib/lxc/gitian/gitian.log exists
 84 2017-10-08 18:11:25 <grubles> but is empty
 85 2017-10-08 18:11:45 <esotericnonsense> I should set up lxc again, I blew away my containers when I sold my old machine, this one is seeming like a keeper
 86 2017-10-08 18:12:42 <arubi> grubles, isn't the container executing a bunch of scripts pushed in by the host?
 87 2017-10-08 18:13:11 <arubi> maybe you could just add a line `cat .../install.log` right after the apt-get update line and run again
 88 2017-10-08 18:16:32 <grubles> oh wait
 89 2017-10-08 18:16:40 <grubles> heh i think i found the install.log
 90 2017-10-08 18:17:34 <arubi> oh cool
 91 2017-10-08 18:17:56 <grubles> https://0bin.net/paste/XDKUSc2iDNqFlOXE#LVlS+5-6mWXigy1ejcle+nKKQ7u9TGGIKEbHj69pd1U
 92 2017-10-08 18:18:51 <esotericnonsense> lol.
 93 2017-10-08 18:18:57 <grubles> 0:-)
 94 2017-10-08 18:19:03 <arubi> yea so Unable to connect to 10.0.2.2:3142 :)
 95 2017-10-08 18:19:12 <grubles> but where does 10.0.2.2 come from...
 96 2017-10-08 18:19:20 <esotericnonsense> it looks like some sort of local package cache to me
 97 2017-10-08 18:19:26 <arubi> probably expecting an apt-cache server there
 98 2017-10-08 18:19:27 <arubi> or a router
 99 2017-10-08 18:19:32 <arubi> \proxy
100 2017-10-08 18:19:36 <esotericnonsense> yeah
101 2017-10-08 18:19:48 <grubles> GITIAN_HOST_IP=10.0.3.2
102 2017-10-08 18:19:55 <grubles> LXC_GUEST_IP=10.0.3.5
103 2017-10-08 18:20:27 <arubi> then maybe these environmental variables aren't passed?
104 2017-10-08 18:20:28 <grubles> i think there's a typo somewhere
105 2017-10-08 18:20:31 <esotericnonsense> old link, but https://askubuntu.com/questions/161427/apt-cacher-wont-work-port-3142-blocked-how-to-open#225511
106 2017-10-08 18:20:40 <esotericnonsense> so 3142 looks related to apt cache
107 2017-10-08 18:21:35 <arubi> right, you normally set up a local apt-cache instance locally so all your vms \ containers \ dockers can use that instead of each fetching from the repos individually
108 2017-10-08 18:24:56 <arubi> <arubi> I'm wondering if sources.list has 10.0.2.2 or resolv.conf somehow makes "repos.ubuntu.com" resolve to 10.0.2.2
109 2017-10-08 18:24:56 <arubi> <arubi> or it's some APT flag being passed, the possibilities are endless when you use repositories!
110 2017-10-08 18:25:09 <arubi> :)
111 2017-10-08 18:26:33 <esotericnonsense> system has been stable for a while now, time to reboot and enable VT and see if that breaks it
112 2017-10-08 18:27:13 <grubles> i don't know why it's trying 10.0.2.2 though when everything else is supposedly configured for a different subnet
113 2017-10-08 18:33:02 <grubles> ok i set br0 and guest ip to 10.0.2.x and now get a different error
114 2017-10-08 18:33:41 <grubles> https://0bin.net/paste/L5J-XnSi7DxbOWuo#zyUBIRBTbjHJAs1xd2uBV4ARpX6vrvGZnomVUbqjpuK
115 2017-10-08 18:35:18 <arubi> invalid option: --detach-sign
116 2017-10-08 18:35:26 <arubi> did you pass this at the wrong step?
117 2017-10-08 18:35:33 <grubles> nope
118 2017-10-08 18:36:06 <grubles> to build i run ./gitian-build.sh -b signer 0.15.0.1
119 2017-10-08 18:36:35 <esotericnonsense> my vague suspicion is that detach-sign is only available in newer versions of gpg but struggling to find refereces
120 2017-10-08 18:36:37 <esotericnonsense> references
121 2017-10-08 18:37:10 <arubi> I'm lost
122 2017-10-08 18:37:44 <esotericnonsense> trusty is old stuff right
123 2017-10-08 18:39:12 <grubles> the lxc host is also debian jessie
124 2017-10-08 18:39:15 <grubles> so also old