< ebfull>
the bitcoin core contributing guidelines are vague on one point; is the author of a pull request free to rebase as their changes become unmergeable?
< ebfull>
it does claim that rebasing and squashing may be asked of the author by "maintainers"
< gmaxwell>
ebfull: just try to not confuse other reviewers, if its gone quiet (like your HTLC) is, I think it's fine to slice and dice the whole thing up.
< ebfull>
thanks. moreover, would you find a policy asking contributors to submit a new pull request to avoid force pushes to their branches to be a silly rule/guideline? (presumably out of a fear of destroying history for reviewers)
< gmaxwell>
it wouldn't be silly but it might be a bit over strong. Esp for trivial patches.
< ebfull>
or trivial rebases
< ebfull>
cool, thanks!
< cfields>
what's the purpose of mapRelay? Just a cache to avoid hitting the mempool for fresh transactions?
< gmaxwell>
no so you will answer transactions you advertised recently even if they're not in mempool anymore. (e.g. just got mined.)
< cfields>
aha, thanks
< Luke-Jr>
hm, is there a reason to do that?
< Luke-Jr>
if it got mined, you're presumably going to resend it as part of the block anyway, right?
< gmaxwell>
who says the peer even fetches the block?
< GitHub66>
[bitcoin] morcos closed pull request #7556: Some cleanup work for mempool and policy estimator (master...cleanupMempool) https://github.com/bitcoin/bitcoin/pull/7556
< btcdrak>
ebfull: we don't have a policy against rebasing in pull requests. most of rerbase and even ask for PR authors to squash where it makes sense.
< sipa>
i tend to rebase continuously, updating individual commits in a way to make the history most logical
< sipa>
until there is significant review
< ebfull>
i agree with your policy (and it's what i'm used to on github); i had other reasons for asking :)
< sipa>
ahERROR: no certificate subject alternative name matches
< sipa>
requested host name `fukuchi.org'.
< sipa>
To connect to fukuchi.org insecurely, use `--no-check-certificate'.
< Luke-Jr>
well, it's technically a bad practice to rebase once published, but most of us tend to ignore that for better or worse :x
< sipa>
Luke-Jr: depends whether you want to optimize for convenience of mergers, or convenience of future reviewers of the code.
< gmaxwell>
There is no such thing as technically in the affairs of men.
< Luke-Jr>
sipa: therefore you rebase until there is nobody to benefit from the no-longer-rebasing? :P
< Luke-Jr>
gmaxwell: technically a bad practice because it screws up git badly ;)
< gmaxwell>
for us we should optimize strongly for long term maintance... which suggests rebasing extensively until it's not useful to do so anymore. :)
< Luke-Jr>
gmaxwell: I could argue against that, but not worth spending time debating it.
< Luke-Jr>
it is what it is
< gmaxwell>
can't make everyone happy.
< Luke-Jr>
maybe some day when Bitcoin is 1.0 and we're all down to <=40 hour weeks with nothing to do, it will make sense to reconsider XD
< GitHub52>
bitcoin/0.12 c5f94f6 Wladimir J. van der Laan: Merge #7780: [0.12] Disable bad-chain alert...
< GitHub181>
[bitcoin] laanwj opened pull request #7781: devtools: Auto-set branch to merge to in github-merge (master...2016_04_github_merge_autobranch) https://github.com/bitcoin/bitcoin/pull/7781
< GitHub124>
bitcoin/master 7539f1a Wladimir J. van der Laan: tests: Make proxy_test work on travis servers without IPv6
< GitHub179>
[bitcoin] laanwj closed pull request #7489: tests: Make proxy_test work on travis servers without IPv6 (master...2016_02_ipv6_tests_conditional) https://github.com/bitcoin/bitcoin/pull/7489
< GitHub124>
bitcoin/master e9723cb Wladimir J. van der Laan: Merge #7489: tests: Make proxy_test work on travis servers without IPv6...
< GitHub3>
[bitcoin] jonasschnelli opened pull request #7783: [Qt] RPC-Console: support nested commands and simple value queries (master...2016/04/qt_console_nested) https://github.com/bitcoin/bitcoin/pull/7783
< GitHub75>
[bitcoin] laanwj closed pull request #7464: Opt-in RBF must be strictly enabled or disabled before GBT can be called (master...master) https://github.com/bitcoin/bitcoin/pull/7464
< instagibbs>
in TestingSetup constructor, is the coinbaseKey.MakeNewKey stuff to just over-write the true genesis block for testing?
< paveljanik>
jonasschnelli, do you have Qt5DBus.pc in 5.6?
< jonasschnelli>
paveljanik: I saw you have found it. Or should I try to locate the file?
< paveljanik>
jonasschnelli, I generated it 8)
< paveljanik>
do you have it in your installation?
< paveljanik>
The official installer has DBus framework...
< jonasschnelli>
sipa: p2penc: you said the size of the size of the encrypted payload should be after the payload itself to increase performance of the AEAD. Right?
< jonasschnelli>
But my humble net/buffer experience tells me the size must be before the payload in order to work with chunked messages transmitting
< gmaxwell>
how can the size be after? how would you find the size? the authentication code should be after so you can read/write it in a streaming manner.
< gmaxwell>
the only way I know to make the size 'after' is to use a self-delimiting encoding which doesn't have an explicit size at all.
< sipa>
jonasschnelli: the size obviously has to go first!
< sipa>
jonasschnelli: but the authentication tag goes after
< jonasschnelli>
Ah. Mixed it up. Right.
< jonasschnelli>
And the tag has a fixed size. Right.
< jonasschnelli>
[09:29:02] <gmaxwell> by sending a message in the channel, "everything that follows will be the next key"
< jonasschnelli>
I also think about the rekeying issue. Do we really need an additional message for that?
< jonasschnelli>
hmm.. I think so.
< jonasschnelli>
Or we could reuse the "encinit" message with a 33 zero bytes as pubkey to indicate "a next key".