< michagogo> PRab: "bitcoin-builder" isn't a thing
< michagogo> You need the `bitcoin` repo (specifically the contrib/gitian-descriptors and depends dirs), your fork of the `gitian.sigs` repo so you can add to it, and the `devrandom/gitian-builder` repo.
< michagogo> PRab: are you building in KVM on a Linux machine? Or in LXC in a VM? Or something else?
< GitHub3> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4ca6ddec4d79...1fc5ca05cacc
< GitHub3> bitcoin/master 2c4ffbc BtcDrak: Create btcdrak-key.pgp
< GitHub3> bitcoin/master 1fc5ca0 Wladimir J. van der Laan: Merge pull request #6805...
< GitHub75> [bitcoin] laanwj closed pull request #6805: Create btcdrak-key.pgp (master...btcdrakpgp) https://github.com/bitcoin/bitcoin/pull/6805
< GitHub11> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1fc5ca05cacc...cd57f344a591
< GitHub11> bitcoin/master 3b363df Paul Rabahy: Updated Prab's PGP Key...
< GitHub11> bitcoin/master cd57f34 Wladimir J. van der Laan: Merge pull request #6807...
< GitHub196> [bitcoin] laanwj closed pull request #6807: Updated Prab's PGP Key (master...NewGPG) https://github.com/bitcoin/bitcoin/pull/6807
< jonasschnelli> wumpus: Hmm... does AddOneShot() (-seednode) retrieves addr data from one node before actually connection to nodes (static ip list)?
< sipa> parse error
< wumpus> jonasschnelli: ThreadDNSAddressSeed queues those connections, if a proxy is used, instead of DNS
< sipa> what is 'queuing a connection' ?
< wumpus> adding it to vOneShots
< wumpus> then in ProcessOneShots, called by ThreadOpenConnections they are handled, one by one
< jonasschnelli> So adding a tor hidden service at seed.<provider>.<tld> (or similar) that redirects to a node running on the same system that can provide .onion addr data would be something that would be worth to achieve?
< wumpus> yes, that avoids using an exit node to conect to your domain
< sipa> we could just only have oneshots for seeding...
< wumpus> e.g. blablablabla.onion:8333 -> seed.bitcoin.jonasschnelli.ch:8333 means a node with Tor can connect to the onion instead, the exit node cannot interfere
< jonasschnelli> so we could flag dns seeds in chainparams.cpp (vSeeds) with a boolean for "tor hidden service"
< wumpus> a flag, or an extra string field per DNS seed 'hidden service alias, if applicable'
< sipa> or more generally, a Network enum
< sipa> to say what network they are on
< sipa> we could have ipv6 ones too
< wumpus> this keeps the DNS seed data for one logical seed together
< wumpus> right sipa
< wumpus> although a *name* can resolve to both ipv4 and ipv6
< wumpus> so that's already possible
< wumpus> (we refer to the DNS seeds by name, not by IP)
< sipa> dns seeding is annoying unflexible, because it doesn't really give ports, service bits, time last seen, ...
< sipa> we could probably use dns seeding as a means to find oneshots
< sipa> and the static ip list too
< jonasschnelli> we could do filtering dns output by quering different domainnames like x.seed.<name>.<tld> ... x stands for service
< wumpus> the reason we have NameProxy is that you cannot see from a name which network it belongs to (unless it happens to be an .onion), so it's just passed to the proxy as-is, having the proxy figure out ipv4/ipv6/...
< sipa> yes, but it doesn't really scale well, plus we already have a protocol for getting address data in a much more featureful way
< sipa> (the p2p protocol)
< sipa> the big advantage of dns is that it's cached and harder tocblock
< wumpus> yes, that was the reason to use DNS
< wumpus> we could use more extensive data in the DNS records now that we use libevent
< wumpus> libevent's resolver can query TXT etc
< jonasschnelli> Yes. And i think that is a big advantage. Having a few oneShot nodes would give them the possibility to collect data, control the network.
< jonasschnelli> Not sure if TXT records will be pass through every DNS without problems
< wumpus> the oneshot nodes are great when DNS cannot be used, e.g. behind Tor, in which case .onion oneshot nodes would be good because the hidden service provides authentication and encryption
< jonasschnelli> But TXT record would give us some possibilities... likes service bits, signed responses, etc.
< wumpus> jonasschnelli: right, just raising it as an option, not saying it's the best
< wumpus> :using DNS seeds only to find oneshot nodes" would be OK with me too
< jonasschnelli> Someone should do a research/analysis how easy it is to deploy TXT records through the dns network.
< wumpus> then again, bbehind a proxy you can't use the DNS seeds so you need to hardcode oneshot nodes anyhow
< sipa> eh, right, that's independent
< wumpus> yes
< Luke-Jr> oneshot = connect and stay connected until it drops, right?
< Luke-Jr> isn't that what we already do for DNS seeds?
< sipa> Luke-Jr: connect, getaddr, disconnect
< Luke-Jr> sipa: that seems like something new?
< sipa> i think it's been in the code since 0.6
< wumpus> no, that's not something new - that's our way of seeding *if* DNS cannot be used, and has been for a long time
< Luke-Jr> hmm
< sipa> we use it instead of dns seeding when we're behind tor
< sipa> as it moves the dns resolving to tor
< Luke-Jr> does it stay connected until one of the other addresses connects successfully?
< wumpus> Luke-Jr: no, it disconnect when it receives an addr message
< fanquake> What are we doing for signing gitian builds now? Doesn't look like the sigs have been added to the detached sigs repo?
< wumpus> fanquake: they have been added
< wumpus> fanquake: attaching the detached signatures should 'just work' as documented in the release process - yes, there
< wumpus> fanquake: (it worked for me)
< fanquake> eh sorry. I was only looking at the master branch...
< GitHub199> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/cd57f344a591...97bee37d4c35
< GitHub199> bitcoin/master 313e7f5 MarcoFalke: Squashed 'src/univalue/' changes from 87d9045..5839ac3...
< GitHub199> bitcoin/master 31f4ba9 MarcoFalke: Merge commit '313e7f5c89d6e72e06efe9255089765b4c5815fe' into HEAD
< GitHub199> bitcoin/master 3b1279f Cory Fields: build: match upstream build change
< GitHub25> [bitcoin] laanwj closed pull request #6788: [trivial] sync univalue subtree (master...MarcoFalke-2015-syncUnivalue) https://github.com/bitcoin/bitcoin/pull/6788
< GitHub74> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/97bee37d4c35...feea3057df47
< GitHub74> bitcoin/master 3a4a458 Matt Corallo: Update bluematt-key, the old one is long-since revoked
< GitHub74> bitcoin/master feea305 Wladimir J. van der Laan: Merge pull request #6812...
< GitHub55> [bitcoin] laanwj closed pull request #6812: Update bluematt-key, the old one is long-since revoked (master...master) https://github.com/bitcoin/bitcoin/pull/6812
< fanquake1> wumpus I think your right about the pgp key confusion
< wumpus> fanquake1: yeh - not saying there shouldn't be a repository of dev pgp keys,but inside the repository itself would not be the right place :)
< fanquake1> Yep. Otherwise we'd end up with hundreds of keys..
< wumpus> that too, but what security would it provide? to check the commits in the repository you use the keys in the repository
< fanquake1> Yes I agree.
< fanquake1> Will we have an rc3, or straight to release now?
< wumpus> depends on whether critical problems are reported with rc2
< wumpus> none yet AFAIK
< GitHub49> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/feea3057df47...01f74999e3df
< GitHub49> bitcoin/master 700f52e Eric Lombrozo: Clarification of unit test build instructions.
< GitHub49> bitcoin/master 01f7499 Wladimir J. van der Laan: Merge pull request #6798...
< GitHub85> [bitcoin] laanwj closed pull request #6798: Clarification of unit test build instructions. (master...unit_test_readme_fix) https://github.com/bitcoin/bitcoin/pull/6798
< GitHub143> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/01f74999e3df...16faccb736ab
< GitHub143> bitcoin/master 8a320c7 MarcoFalke: [trivial] Remove obsolete share/qt/make_windows_icon.sh
< GitHub143> bitcoin/master 3507992 MarcoFalke: [trivial] Make optimize-pngs.py also cover share/pixmaps...
< GitHub143> bitcoin/master 60a8b70 MarcoFalke: [doc] trivial: developer-notes.md covers more than just coding standards
< GitHub180> [bitcoin] laanwj closed pull request #6791: [trivial] Misc cleanup (master...MarcoFalke-2015-trivial2) https://github.com/bitcoin/bitcoin/pull/6791
< GitHub10> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/16faccb736ab...9caaf6ed22d0
< GitHub10> bitcoin/master 3499ce1 Pieter Wuille: Encapsulate CLevelDB iterators cleanly...
< GitHub10> bitcoin/master 0fdf8c8 James O'Beirne: Handle obfuscation in CLevelDBIterator
< GitHub10> bitcoin/master 1488506 James O'Beirne: Add tests for gettxoutsetinfo, CLevelDBBatch, CLevelDBIterator...
< GitHub99> [bitcoin] laanwj closed pull request #6777: Unobfuscate chainstate data in CCoinsViewDB::GetStats (master...obfuscate_fix) https://github.com/bitcoin/bitcoin/pull/6777
< GitHub9> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9caaf6ed22d0...a1d623da3ea4
< GitHub9> bitcoin/master 7d325b9 Johnathan Corgan: zmq: point API link to 4.0 as that is what we are conforming to [Trivial]...
< GitHub9> bitcoin/master a1d623d Wladimir J. van der Laan: Merge pull request #6810...
< GitHub120> [bitcoin] laanwj closed pull request #6810: zmq: point API link to 4.0 as that is what we are conforming to (master...zmq-api-link) https://github.com/bitcoin/bitcoin/pull/6810
< GitHub146> [bitcoin] jmcorgan closed pull request #6811: Adds gpg key for jcorgan (671DA2F7) (master...add-gpg-key) https://github.com/bitcoin/bitcoin/pull/6811
< PRab> michagogo: I got it figured out. FYI, I'm using Windows as my host for a Virtualbox VM.
< GitHub2> [bitcoin] CodeShark opened pull request #6816: BIP9: versionbits (master...versionbits) https://github.com/bitcoin/bitcoin/pull/6816
< GitHub151> [bitcoin] fanquake opened pull request #6817: [doc] Cleanup release-process documentation (master...patch-2) https://github.com/bitcoin/bitcoin/pull/6817
< GitHub118> [bitcoin] dajohi opened pull request #6818: script: Remove magic numbers (master...script_const) https://github.com/bitcoin/bitcoin/pull/6818
< cfields> jcorgan: did you get anywhere with the mingw static link?
< CodeShark> is travis's hard disk full?
< cfields> CodeShark: probably a one-time thing. just force-push something to trigger a rebuild
< cfields> jcorgan: nm, looks like i got it building
< jcorgan> cfields: no, i knew if i waited long enough it would magically start working for you
< cfields> haha. i got curious after you asked yesterday and decided to take a peek
< cfields> so i got it building. but i'll leave it up to you to see if it actually works
< cfields> whoops, nope
< jcorgan> hmm, no idea, will have to replicate here
< cfields> jcorgan: runs successfully with the assertion disabled
< cfields> PRing the build fixes in just a sec
< GitHub38> [bitcoin] theuni opened pull request #6819: WIP: force zeromq to work with static linking+mingw (master...zeromq-mingw) https://github.com/bitcoin/bitcoin/pull/6819
< GitHub45> [bitcoin] theuni opened pull request #6820: build: univalue subdir build fixups (master...univalue-build-fixes) https://github.com/bitcoin/bitcoin/pull/6820
< GitHub58> [bitcoin] domob1812 opened pull request #6821: Avoid duplicate getheaders requests (master...no-duplicate-getheaders) https://github.com/bitcoin/bitcoin/pull/6821
< GitHub58> [bitcoin] MarcoFalke opened pull request #6822: [trivial] minrelaytxfee cleanup (master...MarcoFalke-2015-minRelayTxFeeCleanup) https://github.com/bitcoin/bitcoin/pull/6822
< michagogo> PRab: yeah, that's my setup too. LXC is nice in some ways
< michagogo> In other ways it's really annoying
< michagogo> Seems to break in assorted ways far more often than KVM
< michagogo> PRab: BTW, if you're using LXC, you ~need to upgrade the base image.
< michagogo> I mean, you could not, but then every build will take ages
< michagogo> The make-base-vm script, when you use LXC, creates a clean precise image... using only the precise repo
< michagogo> And not precise-security and precise-updates
< michagogo> PRab: with USE_LXC exported as 1, add the libexec dir in gitian to PATH and run these commands: https://www.irccloud.com/pastebin/vHn9M0LP/
< GitHub8> [bitcoin] gmaxwell closed pull request #6792: Defaults UPNP to off when discovery is disabled. (master...upnp_off_on_ip) https://github.com/bitcoin/bitcoin/pull/6792
< michagogo> Note that you'll need to repeat that whenever there are more updates, because IIRC once you've done this process, gbuild fails if the image isn't fully up to date
< GitHub159> [bitcoin] domob1812 opened pull request #6823: [Trivial] Use constants for DB keys (master...txdb-constants) https://github.com/bitcoin/bitcoin/pull/6823
< sipa> oh, i have another openssl horror story :p
< paveljanik> ;-))
< * BlueMatt> is now whoring out for review of #6722
< instagibbs> related: what's the easiest way to blow up the mempool for testing purposes? My mempool is too small to test.
< instagibbs> Missed out on the 1GB mempool train
< BlueMatt> run testnet, get lots of coins from phantomcircuit and then just createrawtransaction in a loop creating OP_TRUE-no-signature txn?
< phantomcircuit> instagibbs, except do it with regtest
< BlueMatt> well , that
< BlueMatt> but then you have to "mine" blocks
< BlueMatt> with testnet you just make phantomcircuit give you 1000 tnbtc
< instagibbs> hah
< instagibbs> oh yeah, regtest fixes the block issue
< phantomcircuit> noooo my precious coins!
< gavinandresen> instagibbs: qa/rpc-test/smartfees.py generates a lot of transactions in -regtest mode, might be a good starting point for a mempool blowup test
< BlueMatt> phantomcircuit: I'll buy 1 million tnbtc for $0.01
< instagibbs> BlueMatt, that's a reset. Good job Matt.
< phantomcircuit> damn it
< phantomcircuit> now i have to mine them all again
< BlueMatt> lol, testnet4 here we go
< instagibbs> gavinandresen, thanks I'll take a look