< aj>
CubicEarth: i think the limit (if one node has 0 latency and infinite bandwidth) is ~90% -- you'd request 16*9=144=MAX_BLOCKS_IN_TRANSIT_PER_PEER*(m_max_outbound-1) blocks from the other outbounds, but stop requesting from the fast peer after 1024-144 (1024=BLOCK_DOWNLOAD_WINDOW) blocks, at which point your fast peer is gated on the slow peers
< aj>
sdaftuar: i had the thought that it'd be nice if faster peers progressively got larger max_in_transit figures, with everyone starting off at just 1 or 2, but never looked into it. i manually kill the connections to slow nodes when i'm resyncing for a few days or more :-/
< sipa>
aj: yeah, and also making it adaptive based on block sizes
< sipa>
though i guess that mostly matters for the historic part of the chain
< sipa>
but 1024 is huge overkill for recent blocks
< sipa>
eh, 1024 as total window size
< sipa>
you were talking about per-peer limits
< aj>
sipa: yeah, but smaller total window on its own would make slow peers even more of a nuisance
< CubicEarth>
sdaftuar: I don't think it disconnected, but it was only about 15 or 20 minutes to catch up the ~1500 blocks behind
< phantomcircuit>
sipa, monkeying with mutate_depth and use_value_profile resulted in lots of new test cases
< phantomcircuit>
really interesting
< fanquake>
#20644 wont backport cleanly to 0.19 or 0.20, as the version of cctools is older. I've put together what should be an equivalent patch. Would be good for someone to double check it. Just finishing a gbuild
< sipa>
jonasschnelli: whatever is compatible with what gitian does at attaching tome
< jonasschnelli>
stuffing the csalloc_internal signature through gitian signer gives me a "Bitcoin-Qt.app: invalid signature (code or signature have been modified)" when verifying on my mac
< jonasschnelli>
(now testing with the cctools codesign_allocate signature)
< jonasschnelli>
success: using codesign_allocate from cctools-927.0.2_6 (throught MacPorts) works!
< sipa>
yay!
< jonasschnelli>
As for the next steps: how do we pack codesign_allocate into the bitcoin-osx-unsigned.tar.gz?
< jonasschnelli>
(i mean the macOS version)
< sipa>
we don't need to, i think?
< jonasschnelli>
Or shall we imply that the macOS code signature needs to be done on Linux?
< sipa>
you just did one on osx just fine?
< jonasschnelli>
Yeah... but using macports and installing cctools might not be stable in the long run
< jonasschnelli>
probably okay for now
< sipa>
i guess we can add an osx cctools in there
< jonasschnelli>
But I foresee this as a pitfall when someone else builds MacOS signatures in future
< sipa>
my point is more that it doesn't need to be reproducibly built
< jonasschnelli>
yes. Thats right.
< sipa>
it just needs to do the right thing, and we'll know when it doesn't
< jonasschnelli>
Agree. Either we document it well or we make achow101 codesign fail when not using the cctools alloc
< sipa>
or even nicer would be incorporating the allocate tool into the signer
< * jonasschnelli>
pokes achow101 (he might not like that)
< jonasschnelli>
but hey,... finally we can sing on linux. I bet there are a ton of other projects interested in that
< sipa>
we talked about it here a few days ago
< sipa>
iirc he wasn"t planning on adding the allocate part, or at least not at firsr
< jonasschnelli>
The missing codesign_allocate part would probably also be a great source of failue/debugging if other projects starting to use this tool
< jonasschnelli>
(not that this is the scope)
< jonasschnelli>
however, impressive work achow101!
< sipa>
jonasschnelli: for rc4 you'll actually probably just want to use the macos allocate tool
< sipa>
since rc4 has my patch that makes its cctools act like the macos one
< jonasschnelli>
Yes. Sure. Your fix.
< sipa>
ideally you'd use a macos build of the patched cctools
< jonasschnelli>
I mean no fix on Mac
< sipa>
but in all likelihood, the apple one will just work
< jonasschnelli>
Ah.. I tried without (rc3) and it worked...
< jonasschnelli>
I’ll do a testrun with rc4 before publishing the sigs
< jonasschnelli>
(With the apple one)
< sipa>
rc3 used unpatched cctools in its attacher
< sipa>
so you need to use unpatched cctools at signing time too
< jonasschnelli>
sipa: Yes. I tested your fix (patched cctools in attacher) with official_apple tool on signer. Which worked. I guess we can do this also for rc4?
< sipa>
what build did you test?
< jonasschnelli>
Rc3
< jonasschnelli>
Nope... sry. Master
< sipa>
ah yes, master, that makes sense
< jonasschnelli>
But since we backported your fix. It should behave identical (in terms of signing)
< jnewbery>
wumpus MarcoFalke: I think #19829 might be RFM (5 ACKs at various times from MarcoFalke, jonatack, hebasto, sipa, Sjors; reACKs on the latest branch from MarcoFalke, jonatack, Sjors)
< achow101>
jonasschnelli: I would have liked to do the allocate within the tool too, but to do so would essentially require writing a mach-o parser and that was just too much additional work. unfortunately macholib is not sufficient and I couldn't find another library
< jonasschnelli>
achow101: I think its fine. Lets just document it well because otherwise the sigs attachment fail.
< achow101>
sure
< jonasschnelli>
Maybe we can add a simple script to contrib/ that builds code_allocate on mac
< jonasschnelli>
I really dislike depending on macports
< achow101>
could do that
< jonasschnelli>
That would be awesome
< jonasschnelli>
Also,.. I would expect that your tool gets attention from other projects too
< jonasschnelli>
Its really a missing step in distribution (especially iOS, not sure if it works there as well).
< achow101>
It might work on MacOS too, but I didn't check. only found this after writing most of my code
< achow101>
since iOS also uses MachO bundles, it shouldn't be too hard to do both. but I also have no way to test because I can't make iOS builds without an iPhone
< bitcoin-git>
[bitcoin] dongcarl opened pull request #20749: [Bundle 1/n] Prune g_chainman usage related to ::LookupBlockIndex (master...2020-09-libbitcoinruntime-v4) https://github.com/bitcoin/bitcoin/pull/20749
< hebasto>
achow101 "I acutally find a codesigning tool for iOS: https://github.com/appknox/isign" -- if that tool work, should we maintain own tool in long run?
< phantomcircuit>
MarcoFalke, are there rules about what should be pr'd to qa-assets?
< phantomcircuit>
(other than them being merged
< phantomcircuit>
)
< bitcoin-git>
[bitcoin] dongcarl opened pull request #20750: [Bundle 2/n] Prune g_chainman usage in mempool-related validation functions (master...2020-09-reduce-validation-mempool-ccsactiveglobal-usage) https://github.com/bitcoin/bitcoin/pull/20750