< jonasschnelli>
Luke-Jr: IIRC right, modifying .DS_Stores is non trivial. I guess you can't just change it with hexeditor like things. But i'm happy to try if you pass me over a .DS_Store.
< jonasschnelli>
I guess there are tools to modify a DS_Store (which is a non-open apple binary format)
< jonasschnelli>
Yes. I know... need to fix it. Will do *soon*.
< Luke-Jr>
I guess I can hopefully reproduce it in gitian myself :x
< * Luke-Jr>
wonders why gitian has started demanding he enter a password
< Luke-Jr>
debug1: Skipping ssh-dss key ./var/id_dsa for not in PubkeyAcceptedKeyTypes
< wumpus>
bleh, can you bisect it to a change in gitian?
< Luke-Jr>
looks like it's OpenSSH 7.0
< Luke-Jr>
no longer accepts DSS keys by default
< wumpus>
oh that's good to know
< Luke-Jr>
* Support for ssh-dss, ssh-dss-cert-* host and user keys is disabled by default at run-time. These may be re-enabled using the instructions at http://www.openssh.com/legacy.html
< * wumpus>
quickly checks if he has any servers/VPSes with dss keys he could lose access to
< Luke-Jr>
looks like I'm updating Qt in gitian
< wumpus>
also wonder why gitian insists on creating a dsa key in the first place
< Luke-Jr>
devrandom: ^
< gmaxwell>
it would be fast.
< wumpus>
maybe switch to ssh-ed25519
< gmaxwell>
I dunno how widely supported that is, but perhaps that doesn't matter. E.g. centos won't have support for it.
< wumpus>
what matters for gitian is what ubuntu versions support it, at least 14.04 does, but don't know if e.g. 12.04 does
< wumpus>
then again, as this is only used to communciate with a vm on the local host, may be good enough to just add the force-use-dss option. Heck, using no cipher and auth would probably be acceptable...
< gmaxwell>
or just set it to use 2kbit rsa, the generation time is probably not that bad on anything that can compile bitcoin.
< wumpus>
(using ssh to communicate with something running on localhost is kind of redundant :-) )
< wumpus>
changing that would mean regenerating all the base images though
< wumpus>
Luke-Jr: if you change the ssh line in libexec/on-target to include -oHostKeyAlgorithms=+ssh-dss , does that work around the issue?
< Luke-Jr>
you want PubkeyAcceptedKeyTypes=+ssh-dss
< wumpus>
ok
< wumpus>
but in this case it's about what your ssh *sends*, not what is accepted, which shouldn't have changed
< wumpus>
none of the ubuntu versions used for gitian building has OpenSSH 7.0+, it must be the outer ssh refusing to send a dss key
< Luke-Jr>
yes
< wumpus>
so does it work?
< Luke-Jr>
yes
< wumpus>
great
< Luke-Jr>
ugh, the build failure blocks caching the Qt? :/
< wumpus>
yes that's kind of annoying
< wumpus>
any build failure prevents caching of anything
< wumpus>
cached dependencies are not handled separately from the build product, if it fails, it fails completely
< wumpus>
may be possible to split up between a descriptor that just builds the dependencies and one that builds bitcoin, or some other trick
< wumpus>
the idea behind the current design is AFAIK that you use gitian *if* you are virtually sure that the build will pass, as a gitian build is/should be equivalent to a depends builds outside gitian
< wumpus>
(of course, subtle issues with e.g. the VM setup can always interfere so it's a bit brittle...)
< GitHub141>
bitcoin/0.12 8fc174a Wladimir J. van der Laan: net: Add and document network messages in protocol.h...
< * Luke-Jr>
ponders if the cache ought to be a sshfs mount so it doesn't copy all 1 GB of files that don't get used every time
< Luke-Jr>
hm, KVM can do a builtin SMB server for the host..
< wumpus>
yea - if there is some built-in way to share filesystems in the virtualization solution, I think that makes more sense than using sshfs, which is slow
< wumpus>
lxc can simply mount 'host' directories as well
< wumpus>
so using a scratchpad instead of copying everything every time could work
< Luke-Jr>
right
< wumpus>
avoids both the ssh and copy overhead - but it's work, no one ever got around to implementing that, and testing all that
< wumpus>
btw apparently marcofalke had already switched the key type to rsa with https://github.com/devrandom/gitian-builder/pull/107, I do think it should carry a clearer warning that now all the base vms have to be regenerated
< Luke-Jr>
:x
< wumpus>
although re: dependencies, arguably the copy overhead is minimal compared to the time it takes to build, or even prepare a VM for building (all this package upgrading..) so I'm not sure it's that much of a win in practice compared to the work
< Luke-Jr>
maybe not, just annoying ;)
< Luke-Jr>
perhaps I'll just change it to use rsync so the download-to-host step is quicker
< Luke-Jr>
oh blah, we're on ancient Ubuntu
< wumpus>
using rsync would already be nice
< wumpus>
not to ancient to have rsync I suppose?
< * jonasschnelli>
is a fan of rsync/rdiff and rdiff backup
< morcos>
wumpus: 7156 looks like it has a lot of ACK's (remove cs_main from createrawtransaction)
< jamesob>
anyone have suggestions for parts of core that are under-unittested?
< morcos>
jamesob: AcceptToMemoryPool but its one of the more difficult thngs to test.
< jamesob>
in terms of getting the necessary fixture context set up, or something else?
< morcos>
I was going to rework miner_test.cpp at some point, b/c many of them were designed to make sure the mining code did not assume the mempool contained txs that couldn't be mined, but now the mining code does assume that
< jamesob>
hah, I see
< morcos>
yes, in terms of setup. i think there is a test that uses ATMP, but does it on regtest.
< morcos>
which isn't really the right thing for more general ATMP tests
< morcos>
the miner_tests actually construct blocks that can be used on mainnet i think
< morcos>
so maybe that should be abstracted out into a setup that other tests can use
< jamesob>
ATMP?
< morcos>
AcceptToMemoryPool
< jamesob>
ah
< jamesob>
(first cup of coffee has yet to make it down ;)
< jamesob>
yeah, I'll take a look, see if I can grok. may PM you if I get any ideas.
< morcos>
sure
< gmaxwell>
wumpus: No, we shouldn't revert #4906 we should just move forward from it.
< gmaxwell>
I've been giving some though to bringing back the tiered fee behavior bitcoin had untul mid 2012. The earlier logic had a rate table where transactions were added in arrival order, with the required fee gradually going up as the non-fee-sorted candidate block became bigger. In 2012 it was changed to the sorting based selection on the basis that this was the rational behavior to miners, and the '
< gmaxwell>
fullness' of a candidate block was pretty opaque to users.
< gmaxwell>
What the logic was was that up to half the target size, the ordinary fee behavior applied. above half the target the required fee was multiplied by target/(target-current).
< gmaxwell>
What we lost in that change is any backpressure at all, until the limit was met. The belief that this was good for miners was mistaken in any case, since fees relative to orphan impact are small.
< gmaxwell>
And then the need to constantly keep bumping the soft limit to avoid that cliff from the system being poorly stabalized also meant that blocks found fast would glup down a pile of spamflood.
< gmaxwell>
I think we've probably not given this enough thought due to paying too much attention to what short term rational miner behavior would be; when probably really optimizing miner behavior would already not be including most of the transactions today at current feerates.
< zookolaptop>
Right. Bounded rationality. I'm a businessman, and if there are two sources of revenue, one of which gives 100X what the other one gives, then I would tend to say "FUCK that other one! Don't bother me. Don't spend your time thinking about that other one.".
< gmaxwell>
The other thing is that the rational marginal feerate needed to add an attitional transaction to a block actually goes down at the block gets bigger; not up.
< zookolaptop>
Good point.
< gmaxwell>
This is because the possion distributions of blocks, has an exponential distribution of interblock intervals, which has a slope that decreases with more delay. Basically, if you're already screwed latency wise, the marginal harm of including another transaction is less.