Transcript for #bitcoin-dev 2017/10/08

00:28 esotericnonsense i'm trying to understand
00:29 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
00:30 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
00:36 esotericnonsense checksig is a crazy op, I see what people mean about calling it 'OP_DO_BITCOIN'
04:17 arubi esotericnonsense, luckily segwit fixes the crazy :)
04:20 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
14:37 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
14:37 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
14:37 esotericnonsense (for the subscript)
14:40 esotericnonsense either i'm misinterpreting Step 2, or it's just wrong
14:45 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)
14:46 arubi script in part 4 comes from PrevTx.PkScript
14:47 arubi it's the subscript made out of the last executed codesep and onwards
14:47 esotericnonsense ah, that's the crucial bit
14:47 esotericnonsense last _executed_ codesep
14:47 arubi (without the remaining codeseps)
14:49 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)'
14:51 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
14:51 arubi and that prevtx had the whole scriptpubkey in it (in the output itself)
14:51 arubi so you always sign a hash of the entire script anyway
14:52 arubi if you didn't have to sign an input txid, you could do lots of interesting things, but alas :)
14:52 esotericnonsense yeah
14:53 esotericnonsense thanks arubi
14:53 arubi yw
15:00 grubles so i'm getting some errors running the automated gitian builder script
15:01 grubles
15:09 arubi is that the file install.log? seems like apt-get failed?
15:09 grubles no that's just the stdout that the script printed out
15:10 arubi not sure, I never tried the gitian build but fwiw it seems it failed with `apt-get update`
15:11 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
15:19 grubles hm
15:23 grubles lxc-ls shows no containers
15:24 grubles and install.log does not exist on the host
15:28 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
15:45 grubles my guess is it's something qubes os related
15:47 esotericnonsense the upstart errors look interesting, i haven't used gitian, do those come up normally
17:11 grubles esotericnonsense, not sure
17:12 grubles arubi, when building the base vm image it is able to download all of the needed packages
17:12 grubles harumph
17:13 arubi grubles, my second guess is that the ubuntu image uses ipv6 and routing network out of the container somehow fails for ipv6
17:13 arubi I had that happen locally with ubuntu VMs, unrelated to gitian, so maybe that's it..
17:14 grubles maybe
17:14 arubi the ubuntu image I used in a VM tried to reach the repositories on an ipv6 address, but nothing I use supports it
17:16 grubles which image did you use
17:16 arubi it was 16.04.03
17:17 grubles i'm using trusty
17:17 grubles which is...14.04 i think?
17:18 arubi oh, it might do that too.. don't know
17:18 grubles oh wait
17:18 grubles i wiped and started from scrach
17:18 grubles scratch rather
17:19 grubles the build script can't locate python-vm-builder
17:19 grubles but i installed it...
17:19 arubi hm
17:23 grubles oh that's just the script attempting to apt-get it
17:58 grubles hm same error
17:59 arubi grubles, my IT experience says "it's DNS"
18:02 grubles yeah could be
18:05 esotericnonsense it's always DNS
18:05 arubi every. time.
18:06 grubles lol
18:06 grubles i'm not familiar enough with lxc to test if that's the issue
18:07 arubi if you can make it ping something like then you'll know if it can resolve it or not
18:07 esotericnonsense right or just dig inside the container
18:07 arubi but if you can do that, it's better to just make it `cat /path/to/install.log`
18:07 grubles well that's the thing
18:07 grubles it's like it doesn't create the container
18:07 grubles lxc-ls shows nothing
18:07 esotericnonsense grubles: lxc-ls -f? (is it -f?)
18:08 esotericnonsense to show all containers started or otherwise
18:08 grubles -f shows nothing as well
18:08 esotericnonsense it's been a while since I played with lxc
18:08 esotericnonsense hm
18:08 arubi maybe it terminates if the container ends up with an error?
18:09 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
18:09 arubi er, in proxmox*
18:10 grubles terminates as in deletes?
18:10 grubles or otherwise is removed
18:10 esotericnonsense there's a place where your lxc config lives, filesystems exist, etc
18:10 esotericnonsense probably /var/lib/lxc or something like that
18:10 arubi for the dockers the intermediate states are kept
18:10 esotericnonsense if you have a container name or any useful string or whatever you could just `find / -name="thing"` on the root fs
18:11 grubles /var/lib/lxc/gitian/gitian.log exists
18:11 grubles but is empty
18:11 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
18:12 arubi grubles, isn't the container executing a bunch of scripts pushed in by the host?
18:13 arubi maybe you could just add a line `cat .../install.log` right after the apt-get update line and run again
18:16 grubles oh wait
18:16 grubles heh i think i found the install.log
18:17 arubi oh cool
18:17 grubles
18:18 esotericnonsense lol.
18:18 grubles 0:-)
18:19 arubi yea so Unable to connect to :)
18:19 grubles but where does come from...
18:19 esotericnonsense it looks like some sort of local package cache to me
18:19 arubi probably expecting an apt-cache server there
18:19 arubi or a router
18:19 arubi \proxy
18:19 esotericnonsense yeah
18:19 grubles GITIAN_HOST_IP=
18:19 grubles LXC_GUEST_IP=
18:20 arubi then maybe these environmental variables aren't passed?
18:20 grubles i think there's a typo somewhere
18:20 esotericnonsense old link, but
18:20 esotericnonsense so 3142 looks related to apt cache
18:21 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
18:24 arubi <arubi> I'm wondering if sources.list has or resolv.conf somehow makes "" resolve to
18:24 arubi <arubi> or it's some APT flag being passed, the possibilities are endless when you use repositories!
18:25 arubi :)
18:26 esotericnonsense system has been stable for a while now, time to reboot and enable VT and see if that breaks it
18:27 grubles i don't know why it's trying though when everything else is supposedly configured for a different subnet
18:33 grubles ok i set br0 and guest ip to 10.0.2.x and now get a different error
18:33 grubles
18:35 arubi invalid option: --detach-sign
18:35 arubi did you pass this at the wrong step?
18:35 grubles nope
18:36 grubles to build i run ./ -b signer
18:36 esotericnonsense my vague suspicion is that detach-sign is only available in newer versions of gpg but struggling to find refereces
18:36 esotericnonsense references
18:37 arubi I'm lost
18:37 esotericnonsense trusty is old stuff right
18:39 grubles the lxc host is also debian jessie
18:39 grubles so also old