1 2017-08-04 06:12:46	0|venzen|wumpus: https://www.reddit.com/r/Bitcoin/comments/6rijhe/bitcoin_core_binary_signing_keys_not_matching/
  2 2017-08-04 06:13:39	0|venzen|wumpus: i assume those are different keys for different uses
  3 2017-08-04 07:44:55	0|Chicago|venzen, just ask for the long keyid-format to confirm whether you're using the correct signatures with anything you find.  The short keyid is prone to collisions.  a 'keyid-format 0xlong' in your gpg.conf will ensure gpg always shows you the long keyid-format.
  4 2017-08-04 07:47:24	0|Chicago|venzen, another place to find keys to import is over here, https://github.com/bitcoin/bitcoin/tree/master/contrib/gitian-keys
  5 2017-08-04 07:49:58	0|venzen|Chicago: thanks, I'll post the link you provide to the r/bitcoin post. The OP seems to be confused and I figured wumpus should be aware of the post
  6 2017-08-04 07:52:23	0|Chicago|venzen, I would presume the bitcoin.org (over HTTPS) hosted key is an order of magnitude more trustworthy than anything you randomly find by looking for a short string at the MIT PGP server.
  7 2017-08-04 07:54:22	0|venzen|Chicago: agree, PGP key servers being neither secure nor authoritative. Theymos clarified the issue for the OP, so wumpus needn't respond
  8 2017-08-04 07:54:59	0|Chicago|yeah, looks like he got to it 15 minutes ago on the Bitcoin subreddit
  9 2017-08-04 08:00:51	0|gmaxwell|sipa: perhaps we need a three-liner to detect after loading the block index if the abc first block is in it and marked valid, and if so, trigger the reindex needed message. :(
 10 2017-08-04 08:01:13	0|gmaxwell|sipa: I've encounter several other people running into chaos due to abc corrupted blockchains.
 11 2017-08-04 08:01:53	0|timothy|gmaxwell: the real problem is that the broken forks (aka abc) uses the bitcoin-core data directory
 12 2017-08-04 08:02:11	0|timothy|instead of using another one
 13 2017-08-04 08:03:41	0|gmaxwell|timothy: yes, sure, but they were asked to not do these moronic things that would cause harm to users and rather rudely refused to.  We can't control them... what we can do is mitigate what harm we can.
 14 2017-08-04 08:04:09	0|gmaxwell|reuse of the datadir is hardly the worse of their sins, reuse of the address version will likely cause the most funds loss eventually.
 15 2017-08-04 08:05:30	0|timothy|so do you think SIGHASH_FORKID is not enough to protect them?
 16 2017-08-04 08:06:28	0|gmaxwell|timothy: no man, already people are losing funds because they swap btc and bcash addresses; this is not surprisign either, because a few altcoins have previously made this mistake and it caused a lot of funds losses there too.
 17 2017-08-04 08:07:45	0|timothy|oh right, using compatible addresses can generate chaos for users
 18 2017-08-04 08:08:11	0|gmaxwell|it's not quite as bad as the ethereum checksumless stuff, but ... not that much better either.
 19 2017-08-04 08:15:06	0|goatpig|it's terribly unsafe
 20 2017-08-04 08:15:27	0|goatpig|there's a major attack vector where someone can send you an address that's a nested SW script
 21 2017-08-04 08:15:47	0|goatpig|if you fill that on the bcash chain, you just created a anyone can pay output
 22 2017-08-04 08:16:20	0|goatpig|their approach is basically killing P2SH on that chain
 23 2017-08-04 08:16:29	0|goatpig|Bitcoin is unaffected though
 24 2017-08-04 08:24:48	0|gmaxwell|we might end up inadvertantly rescuing them with a more rapid adoption of BIP173 though then there is the same idiocy that may happen four months from now. :( and maybe we should hold back posting the BIP173 integration from core so that it's distinct from the next of these dumb forks.
 25 2017-08-04 08:26:37	0|goatpig|bech32 address or not, I'd stay far far away from P2SH on the bcash chain
 26 2017-08-04 08:27:35	0|goatpig|they could have simply changed the script hash prefixes and that would have gone a long way to avoid this mess
 27 2017-08-04 08:31:46	0|gmaxwell|goatpig: for a lot of places paying to a from plain 1xx address isn't much better.
 28 2017-08-04 08:32:23	0|goatpig|i just paid to a bitpay address a couple hours ago and had that same reaction
 29 2017-08-04 08:32:24	0|gmaxwell|If my keys are in a hsm, in some offline host, whatever. Fat freeking chance that I'm going to go and load up bcc potential key leaking malware any time soon to go recover lost funds sent to them.
 30 2017-08-04 08:32:49	0|goatpig|im implementing bch signing in armory as we speak =D
 31 2017-08-04 08:33:04	0|gmaxwell|if bcash price isn't ~0 in short order there will also be a hundred more of these things.
 32 2017-08-04 08:33:08	0|goatpig|at least my users won't have to expose their coins to god knows what's in that code
 33 2017-08-04 08:33:54	0|gmaxwell|(not that bch is even the first altcoin to airdrop on bitcoin users, just the first with a highly funded marketing effort behind it)
 34 2017-08-04 08:34:11	0|goatpig|i didn't even know of the previous attempts
 35 2017-08-04 08:34:25	0|goatpig|learned of them through the bch "insistance"
 36 2017-08-04 08:39:45	0|gmaxwell|goatpig: I knew of two of them, learned of a few more since.
 37 2017-08-04 08:40:48	0|goatpig|what really pissed me off besides the hurried out fork is that they didn't bother contacting people in the ecosystem, nor do i have any idea where to look for their testnet, if they even have one
 38 2017-08-04 08:41:21	0|goatpig|no wonder Coinbase is planning to support them in 2018!
 39 2017-08-04 08:41:46	0|gmaxwell|they don't have  one.
 40 2017-08-04 08:42:02	0|goatpig|man... i was afraid it would be the case
 41 2017-08-04 08:42:04	0|arubi|it appears you have to sign up to the testnet
 42 2017-08-04 08:42:04	0|arubi|I was just thinking maybe there should be an open testnet
 43 2017-08-04 08:42:20	0|goatpig|sign up? wth
 44 2017-08-04 08:42:57	0|gmaxwell|yea, I was talking to some people about what it would take to support this... there are people out there that have automatically managed keys in HSMs which can't deal with this stuff without being reinitialized, and where any major modification to the software will require an outside security and crypto assessment with a $200k-ish pricetag.
 45 2017-08-04 08:42:57	0|goatpig|it's like they want the pretense of open source, but every step they take is to obfuscate development and keep the ecosystem at bay save a few hand picked actors
 46 2017-08-04 08:43:05	0|arubi|I saw a message on one of their subreddits, I think it was "ftrader" that told the person asking about it that he'll need to sign up for their slack
 47 2017-08-04 08:43:11	0|arubi|at least iirc, I didn't bother
 48 2017-08-04 08:43:37	0|gmaxwell|arubi: oh they edited that post to now say "sign up"
 49 2017-08-04 08:43:41	0|wallet42|where/how does segwit block data is stored on disk? is it appended to the block in the *.blk files?
 50 2017-08-04 08:43:47	0|gmaxwell|https://github.com/Bitcoin-ABC/bitcoin-abc/issues/36#issuecomment-318662274 it didn't even say that.
 51 2017-08-04 08:44:30	0|gmaxwell|wallet42: what? it's stored in the blocks just like it's sent on the wire. you're probably thinking segwit seperates signatures, it does not, it leaves them out of txids, but they're inside transactions.
 52 2017-08-04 08:44:56	0|gmaxwell|goatpig: as far as testnet goes, it doesn't pass the unit/system tests that it ships with.
 53 2017-08-04 08:45:07	0|arubi|right that's it.  was on github
 54 2017-08-04 08:45:12	0|goatpig|nice
 55 2017-08-04 08:46:19	0|gmaxwell|goatpig: I was trying to make a safer version of it by reverting most of the code to things tracable to audited code; then trying their tests to see what the changes broke... wasted a bunch of time because the tests never passed to begin with.
 56 2017-08-04 08:46:50	0|goatpig|let's look at it like this: at least they build!
 57 2017-08-04 08:47:09	0|arubi|now I know what I'm doing tomorrow
 58 2017-08-04 08:47:20	0|arubi|regtest didn't complain, at least that helped with the sighash thing
 59 2017-08-04 08:48:10	0|arubi|well, didn't break more like it
 60 2017-08-04 08:57:19	0|jonasschnelli|achow101 Ping. I have read on the gitian related github repos that you also had problems with LXC and "init.lxc: failed to mount /dev/shm : No such file or directory"
 61 2017-08-04 08:57:21	0|jonasschnelli|Any idea?
 62 2017-08-04 08:57:30	0|jonasschnelli|... how to solve this?
 63 2017-08-04 08:57:52	0|jonasschnelli|SInce updating from jessie to strech (debian 8 - 9) I'm no longer capable to build with LXC
 64 2017-08-04 09:01:01	0|aj|jonasschnelli: do you need to make a symlink to /run/shm?
 65 2017-08-04 09:01:35	0|jonasschnelli|aj: can you elaborate more in detail?
 66 2017-08-04 09:02:06	0|jonasschnelli|symlink /run/shm to /dev/shm?
 67 2017-08-04 09:02:24	0|aj|jonasschnelli: not accurately without checkng some details. :) /dev/shm got renamed to /run/shm (and maybe removed entirely?)
 68 2017-08-04 09:04:21	0|jonasschnelli|lrwxrwxrwx 1 root root 8 Aug  3 21:51 /run/shm -> /dev/shm
 69 2017-08-04 09:04:38	0|jonasschnelli|There is already a symlink to /dev/shm? :/
 70 2017-08-04 09:05:03	0|jonasschnelli|I guess the problem lies where gitian create it's containers with debootstrap instead of lxc-create
 71 2017-08-04 09:05:21	0|jonasschnelli|(which probably creates the incompatibility with stretch)(
 72 2017-08-04 09:07:12	0|jonasschnelli|And I guess "init.lxc: failed to mount /dev/shm : No such file or directory" is raised within the container.
 73 2017-08-04 09:08:02	0|aj|jonasschnelli: hmm, is /run/shm in the container a symlink or directory or non-existant?
 74 2017-08-04 09:10:17	0|jonasschnelli|aj: within the container, ls: cannot access /dev/shm: No such file or directory
 75 2017-08-04 09:10:27	0|jonasschnelli|I'll try to create it in bootstrap fixes
 76 2017-08-04 09:12:44	0|aj|jonasschnelli: the jessie release notes suggest setting autodev=1 -- https://www.debian.org/releases/jessie/amd64/release-notes/ch-information.en.html#lxc-upgrade-issues
 77 2017-08-04 09:12:53	0|aj|jonasschnelli: seems like that shouldn't be your issue though
 78 2017-08-04 09:13:05	0|jonasschnelli|Oh.. Let me try that
 79 2017-08-04 09:14:21	0|jonasschnelli|aj: hmm.. added lxc.autodev = 1 to my gitian builders etc/lxc.config.in
 80 2017-08-04 09:14:28	0|jonasschnelli|But still get the same error while gbuild
 81 2017-08-04 09:16:40	0|jonasschnelli|aj: It worked on jessie... it does not work on stretch
 82 2017-08-04 09:18:05	0|aj|jonasschnelli: i think as of stretch autodev=1 is the default
 83 2017-08-04 09:18:50	0|aj|jonasschnelli: yeah, jessie was 1.0.6, stetch is 2.0.7, it changed around 1.1.2
 84 2017-08-04 09:19:28	0|jonasschnelli|lxc.autodev = 0 solves the issue "init.lxc: failed to mount /dev/shm : No such file or directory"
 85 2017-08-04 09:19:32	0|jonasschnelli|Though other error appear. :)
 86 2017-08-04 09:19:47	0|jonasschnelli|tar: cache: Cannot open: No such file or directory
 87 2017-08-04 09:19:47	0|jonasschnelli|tar: Error is not recoverable: exiting now
 88 2017-08-04 09:20:12	0|aj|jonasschnelli: https://github.com/moby/moby/issues/12912 has a change to make it actually create /dev/shm when trying to mount, but it's supposed to be applied already the way i read it
 89 2017-08-04 09:20:53	0|jonasschnelli|aj: Thanks. I'll look into it after lunch...
 90 2017-08-04 09:24:18	0|Chicago|Why not continue using Jesse, it hasn't reached end-of-life quite yet.
 91 2017-08-04 09:27:53	0|jonasschnelli|Chicago: I have already upgraded and downgrade seems painful
 92 2017-08-04 09:28:04	0|jonasschnelli|But I would not upgrade again...
 93 2017-08-04 09:32:14	0|Chicago|Just for Gitian building, using a Virtualbox instance seems to be an easy 5 minute build.  If using QEMU/LXC, then maybe more time consuming.
 94 2017-08-04 09:32:36	0|Chicago|I'm doing it with libvirtd and Virtual Manager, its pretty efficient and fast when creating a new Gitian VM.
 95 2017-08-04 09:33:09	0|aj|jonasschnelli: is the container ubuntu or debian?
 96 2017-08-04 09:33:25	0|aj|jonasschnelli: (is the config available somewhere?)
 97 2017-08-04 09:37:12	0|aj|jonasschnelli: oh, it's gitian, duh
 98 2017-08-04 09:42:03	0|aj|jonasschnelli: adding """lxc.mount.entry=shm dev/shm tmpfs rw,nodev,noexec,nosuid,relatime,mode=1777,create=dir 0 0
 99 2017-08-04 09:42:30	0|aj|""" to lxc.config.in and leaving autodev unset (=1) is my best guess, i think
100 2017-08-04 10:51:41	0|jonasschnelli|aj: Okay. Let me try that
101 2017-08-04 11:01:46	0|jonasschnelli|aj: the mount error is gone with the additional lxc.mount point, but there are still other issues... mainly:
102 2017-08-04 11:01:46	0|jonasschnelli|lxc-execute: cgroups/cgfsng.c: cgfsng_create: 1363 No such file or directory - Failed to create /sys/fs/cgroup/systemd//lxc/gitian: No such file or directory
103 2017-08-04 11:01:46	0|jonasschnelli|lxc-execute: cgroups/cgfsng.c: create_path_for_hierarchy: 1306 Path "/sys/fs/cgroup/systemd//lxc/gitian" already existed.
104 2017-08-04 11:02:02	0|jonasschnelli|as well as...sudo: unknown user: ubuntu
105 2017-08-04 11:02:02	0|jonasschnelli|sudo: unable to initialize policy plugin
106 2017-08-04 11:02:34	0|jonasschnelli|I can "adduser debian" in the boostrap fixups..., but not sure about the systemd/lxc issue
107 2017-08-04 11:11:26	0|jonasschnelli|Oh.. after creating the user in bootstrap.fixups and giving it the right permissions, the gitian build has at least started...
108 2017-08-04 11:11:47	0|jonasschnelli|(including aj lxc mountpoint fix above)
109 2017-08-04 11:15:49	0|Chicago|jonasschnelli, awesome :)
110 2017-08-04 11:16:47	0|aj|jonasschnelli: wow, what a mess :(
111 2017-08-04 11:17:23	0|jonasschnelli|Chicago: Do you use VirtualBox instead of LXC/KVM(qemu) for the guest/build VM? Of for the host VM?
112 2017-08-04 11:21:01	0|Chicago|jonasschnelli, I'm currently very happy with libvirtd ran through Virtual Manager with Debian 8 as the guest VM operating system.  Gitian decides which OS is used for the image, in the recipe. (currently its Trusty)
113 2017-08-04 11:21:24	0|Chicago|The host OS is Gentoo GNU/Linux x86_64.
114 2017-08-04 11:22:00	0|jonasschnelli|Hmm... Chicago: I use a "physical debian 9" as the host for gitian (no VM in between),... gitian then spinns the LXC ubuntu trusty on that physical host.
115 2017-08-04 11:22:39	0|jonasschnelli|I wonder if using the gitians VirtualBox way to deterministically build is faster then LXC... though I doubt it.
116 2017-08-04 11:23:24	0|Chicago|Well... there are tricks to it.  You can update the Gitian configuration to use more memory and processors than the 3000M of RAM and 2 vCPU it calls for out-of-the-box.
117 2017-08-04 11:28:22	0|jonasschnelli|Chicago: indeed. Speeding up with mem and parallelism makes sense... also dependency caching can maybe be improved
118 2017-08-04 11:29:42	0|Chicago|hell... if you have a big box, put everything into a tmpfs
119 2017-08-04 11:29:58	0|Chicago|40G ain't much RAM on modern gear.
120 2017-08-04 11:56:34	0|jonasschnelli|Chicago: I doubt it's much faster then running on the 1GB/s SSD
121 2017-08-04 11:56:58	0|jonasschnelli|disk access seems to be not the issue. Compiling is usual pure CPU, not?
122 2017-08-04 11:58:43	0|Chicago|VT-x extensions will give the compiler access to the vCPU, but compiling and linking still has disk i/o and SSD is still at least > 1 order of magnitude slower then RAM.
123 2017-08-04 12:27:40	0|jonasschnelli|Can't the updating apt and "Upgrading system" in gitian be cached?
124 2017-08-04 12:27:47	0|jonasschnelli|Installing additional packages (log in var/install.log)
125 2017-08-04 12:27:47	0|jonasschnelli|Updating apt-get repository (log in var/install.log)
126 2017-08-04 12:27:47	0|jonasschnelli|Upgrading system, may take a while
127 2017-08-04 12:27:57	0|jonasschnelli|Those steps seems to take a couple of minues.
128 2017-08-04 12:28:16	0|jonasschnelli|Caching as long as the hash of the descriptor hasn't changed?
129 2017-08-04 12:30:06	0|Chicago|Well, you know once the base image is built; it could be a few weeks between Bitcoin release cycles; and so it has to build the dependency graph and do the package installations deterministically such that if you built an image last month with Trusty and I built an image today with Trusty, we both end up getting the exact same depgraph when we go to build everything.
130 2017-08-04 12:30:33	0|Chicago|The caching comes from apt-cacher-ng so that you don't have to repeatedly fetch those files.
131 2017-08-04 12:51:32	0|MarcoFalke|Would it be sufficient to call invalidateblock $abc_block ?
132 2017-08-04 12:52:02	0|MarcoFalke|sorry, replied to scrollback.
133 2017-08-04 13:16:04	0|jonasschnelli|Build server is up and running... thanks to aj!
134 2017-08-04 13:16:07	0|jonasschnelli|https://bitcoin.jonasschnelli.ch/build/245
135 2017-08-04 13:34:27	0|jonasschnelli|It seems like it won't get faster then 7min for a gitian OSX build. --num-make is now at 6 and mem at 6000
136 2017-08-04 13:34:33	0|jonasschnelli|Windows takes 14...
137 2017-08-04 13:34:39	0|jonasschnelli|Linux >20 because of the three archs
138 2017-08-04 16:02:58	0|wumpus|venzen: yes that's correct, thanks for clarifying
139 2017-08-04 16:04:07	0|wumpus|jonasschnelli: 7 minutes for a full build? that's pretty impressive
140 2017-08-04 16:08:02	0|wumpus|and yeah, more archs is expected to be linearly slower in their number
141 2017-08-04 16:08:18	0|wumpus|although it helps we don't build qt executables for ARM - I guess
142 2017-08-04 16:09:00	0|wumpus|although building the GUI shouldn't add that much time, given that qt itself is cached ofcourse, building qt itself is a whole other story
143 2017-08-04 16:11:53	0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #10988: qt: Increase BLOCK_CHAIN_SIZE constants (06master...062017_08_qt_block_chain_size) 02https://github.com/bitcoin/bitcoin/pull/10988
144 2017-08-04 16:42:44	0|jcorgan|inb4 someone interprets that as BLOCK_SIZE
145 2017-08-04 16:51:24	0|wumpus|lol
146 2017-08-04 16:53:48	0|wumpus|I can see the reddit troll posts already "wladimir j. van der laan proposes to change block size to 150GB"
147 2017-08-04 17:02:06	0|luke-jr|lol
148 2017-08-04 17:04:32	0|luke-jr|so anyhow, what's with the release notes saying current wallet RPCs don't work with multiwallet in 0.15?
149 2017-08-04 17:04:45	0|luke-jr|I thought no matter what a new interface does, we will be backward compatible⁇
150 2017-08-04 17:48:04	0|paveljanik|wumpus, 150GB or 140GB?
151 2017-08-04 17:50:40	0|paveljanik|the first comment says 150GB, but the code is changed to 140
152 2017-08-04 17:54:55	0|Lauda|I think he meant to do 150 GB. The current size is 135 + 15GB mentioned in the commit.
153 2017-08-04 18:20:24	0|jonasschnelli|wumpus: 7min for OSX is quick... though 28 min Linux seems slow...
154 2017-08-04 18:23:15	0|achow101|jonasschnelli: I never figured out how to fix the lxc problem. I just switched to using kvm instead after trying too many things that didn't work
155 2017-08-04 18:23:22	0|achow101|if you could figure it out though, that would be great
156 2017-08-04 18:30:55	0|jonasschnelli|achow101: I solved it on my end
157 2017-08-04 18:31:14	0|jonasschnelli|achow101: see https://github.com/devrandom/gitian-builder/issues/147
158 2017-08-04 18:31:20	0|jonasschnelli|Couldn't do it without help from aj
159 2017-08-04 18:54:44	0|bitcoin-git|[13bitcoin] 15luke-jr opened pull request #10989: RPC: Restore backward compatibility, in multiwallet mode (06master...06multiwallet_rpccompat) 02https://github.com/bitcoin/bitcoin/pull/10989
160 2017-08-04 19:32:51	0|sipa|wumpus: i've shortened the notice about windows XP in the release notes, let me know if you think it deserves a longer text
161 2017-08-04 19:33:49	0|sipa|jnewbery: i've added a paragraph on non-atomic flushing, as that is also a nice performance boost
162 2017-08-04 20:21:09	0|earlz|Anyone ever seen this when building from Gitian? symbol pthread_setname_np from unsupported version GLIBC_2.12
163 2017-08-04 21:55:19	0|jnewbery|sipa: thanks! The only item outstanding in #9889 is a note on fee estimation improvements. I'll do that early next week
164 2017-08-04 21:55:20	0|gribble|https://github.com/bitcoin/bitcoin/issues/9889 | TODO for release notes 0.15.0 · Issue #9889 · bitcoin/bitcoin · GitHub
165 2017-08-04 22:08:17	0|bitcoin-git|[13bitcoin] 15gandrewstone opened pull request #10990: 0 locktime issue (06master...06fix0locktimebug) 02https://github.com/bitcoin/bitcoin/pull/10990