< jonasschnelli>
"Travis early exit to cache current state"
< luke-jr>
I think we're supposed to just restart it when that happens
< aj>
jonasschnelli: "downloading/compiling took too long for tests to succeed, but if we timeout it won't cache and retry will fail in the same way, but if we fail deliberately it'll cache and next time might work" aiui
< jonasschnelli>
hmm...
< jonasschnelli>
So should I just restart the job until it succeeds within time?
< jonasschnelli>
what luke-jr said
< aj>
or fails for a real reason, yeah, i think so
< bitcoin-git>
bitcoin/master fa1c073 MarcoFalke: contrib: gh-merge: Include review comments in merge commit
< bitcoin-git>
bitcoin/master 848ec56 Wladimir J. van der Laan: Merge #15643: contrib: gh-merge: Include ACKs in merge commit
< bitcoin-git>
[bitcoin] laanwj merged pull request #15643: contrib: gh-merge: Include ACKs in merge commit (master...1903-ghMergeAck) https://github.com/bitcoin/bitcoin/pull/15643
< wumpus>
luke-jr: that's ... terrible "this automation takes too long so we've implemented manual button-clicking labor for the users !"
< wumpus>
I guess the build/testing times are really getting out of hand
< Sentineo>
will there be an rc3? Where can I track it? I mean I want to help with gitian build when needed, just do not have time to read everything on irc, so I do not want to miss when a build is needed.
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #15620: rpc: Uncouple non-wallet rpcs from maxTxFee global (master...1903-rpcNoMaxTxFee) https://github.com/bitcoin/bitcoin/pull/15620
< jamesob>
at what point does a move-only commit stop being move-only? i.e. if I move the declaration of a class from foo.cpp -> foo.h, but then have to add a single line in order to fix a resulting linker error, is the commit still move-only?
< promag>
instead of period checking, could use that signal?
< ryanofsky>
sure
< promag>
not sure if jnewbery wants to do that there, or in another
< jnewbery>
promag: I just responded to your question about using UpdatedBlockTip as a trigger for resending wallet txs. I think it's bad for privacy.
< gmaxwell>
whats going on there? the existing behavior is that the resends are on a random timer that is gated by the tip changing, so you don't get things like handing the node a block and then see it send transactions... but also so it avoids resending when the situation is no different... we should probably be more intelligent and only resend if the transaction was in the top block worth of our
< gmaxwell>
mempool before the last block (otherwise, why would we expect it to have been mined)
< jnewbery>
right, that's the existing behaviour, and my PR would keep that behaviour
< jnewbery>
promag suggested a simplification to my pr #15632 which if I'm understanding would change the behaviour to only resend immediately following a tip update
< jnewbery>
which I'm saying would make rebroadcasts more obvious
< gmaxwell>
K. agreed, thats the opposite direction we need to go, right now we make many unnecessary rebroadcasts and they're REALLY identifying.
< jnewbery>
I don't understand "only resend if the transaction was in the top block worth of our mempool before the last block (otherwise, why would we expect it to have been mined)"
< dongcarl>
sipa: Looking at your original PR that added support for onion addresses... 70f7f0038592a28e846f02d084f0119fc34eb52f. Any particular reason we used onioncat's range and encoding or was it just a choice?
< sipa>
dongcarl: schelling point; if you'd use something else, what would you pick?
< gmaxwell>
picking something else would risk colliding with some other uses, better to reuse an existing space-squat.
< gmaxwell>
jnewbery: the idea behind the current rebroadcast behavior is that unless the tip has changed we don't have any reason to expect our transaction to have been mined, so the rebroadcast is pointless, since the txn might just be sitting waiting to be mined and all the rebroadcasts in the world won't speed that up.
< dongcarl>
Makes sense. No particular opinion, just wanted to make sure I wasn't missing any context as I'm adding documentation to net
< gmaxwell>
(I mean the idea behind why it watches the tip)
< gmaxwell>
jnewbery: But thats still too rebroadcast heavy. If the tip changed but at our transaction wasn't near the top of our mempool, well it shouldn't have been mined then either.
< gmaxwell>
jnewbery: so right now if you make a txn that won't get mined for 12 blocks, you'll end up potentially rebroadcasting 12 times, even though it was in miners mempools the whole time. I've also seen network spies that appear to be attempting to exploit the rebroadcasting.
< gmaxwell>
So ideally we'd suppress rebroadcasting during periods when the txn is nowhere near the top. Rebroadcasting then is pointless and only serves to deanon us.