1 2016-04-01 00:37:41	0|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?
  2 2016-04-01 00:38:22	0|ebfull|it does claim that rebasing and squashing may be asked of the author by "maintainers"
  3 2016-04-01 00:40:09	0|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.
  4 2016-04-01 00:41:28	0|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)
  5 2016-04-01 00:42:09	0|gmaxwell|it wouldn't be silly but it might be a bit over strong.   Esp for trivial patches.
  6 2016-04-01 00:42:19	0|ebfull|or trivial rebases
  7 2016-04-01 00:42:23	0|ebfull|cool, thanks!
  8 2016-04-01 01:47:32	0|cfields|what's the purpose of mapRelay? Just a cache to avoid hitting the mempool for fresh transactions?
  9 2016-04-01 01:48:45	0|gmaxwell|no so you will answer transactions you advertised recently even if they're not in mempool anymore. (e.g. just got mined.)
 10 2016-04-01 01:50:10	0|cfields|aha, thanks
 11 2016-04-01 02:13:13	0|Luke-Jr|hm, is there a reason to do that?
 12 2016-04-01 02:13:30	0|Luke-Jr|if it got mined, you're presumably going to resend it as part of the block anyway, right?
 13 2016-04-01 02:17:08	0|gmaxwell|who says the peer even fetches the block?
 14 2016-04-01 02:33:25	0|GitHub137|[13bitcoin] 15morcos closed pull request #7557: Encapsulate options for mempool policy (06master...06policyOptions) 02https://github.com/bitcoin/bitcoin/pull/7557
 15 2016-04-01 02:34:52	0|GitHub66|[13bitcoin] 15morcos closed pull request #7556: Some cleanup work for mempool and policy estimator (06master...06cleanupMempool) 02https://github.com/bitcoin/bitcoin/pull/7556
 16 2016-04-01 06:06:00	0|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.
 17 2016-04-01 06:06:45	0|sipa|i tend to rebase continuously, updating individual commits in a way to make the history most logical
 18 2016-04-01 06:06:56	0|sipa|until there is significant review
 19 2016-04-01 06:07:30	0|ebfull|i agree with your policy (and it's what i'm used to on github); i had other reasons for asking :)
 20 2016-04-01 07:20:05	0|sipa|ahERROR: no certificate subject alternative name matches
 21 2016-04-01 07:20:05	0|sipa|requested host name `fukuchi.org'.
 22 2016-04-01 07:20:05	0|sipa|To connect to fukuchi.org insecurely, use `--no-check-certificate'.
 23 2016-04-01 07:20:06	0|sipa|OpenSSL: error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error
 24 2016-04-01 07:20:09	0|sipa|in travis?
 25 2016-04-01 07:26:29	0|jouke|/win 38
 26 2016-04-01 07:26:32	0|jouke|...
 27 2016-04-01 07:27:29	0|sipa|jouke: no, win 10
 28 2016-04-01 08:24:56	0|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
 29 2016-04-01 08:27:03	0|sipa|Luke-Jr: depends whether you want to optimize for convenience of mergers, or convenience of future reviewers of the code.
 30 2016-04-01 08:27:42	0|gmaxwell|There is no such thing as technically in the affairs of men.
 31 2016-04-01 08:28:07	0|Luke-Jr|sipa: therefore you rebase until there is nobody to benefit from the no-longer-rebasing? :P
 32 2016-04-01 08:28:26	0|Luke-Jr|gmaxwell: technically a bad practice because it screws up git badly ;)
 33 2016-04-01 08:28:33	0|gmaxwell|for us we should optimize strongly for long term maintance... which suggests rebasing extensively until it's not useful to do so anymore. :)
 34 2016-04-01 08:29:09	0|Luke-Jr|gmaxwell: I could argue against that, but not worth spending time debating it.
 35 2016-04-01 08:29:19	0|Luke-Jr|it is what it is
 36 2016-04-01 08:31:26	0|gmaxwell|can't make everyone happy.
 37 2016-04-01 08:31:37	0|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
 38 2016-04-01 12:17:14	0|GitHub52|13bitcoin/060.12 148692626 15BtcDrak: Disable bad chain alerts...
 39 2016-04-01 12:17:14	0|GitHub52|13bitcoin/060.12 14c5f94f6 15Wladimir J. van der Laan: Merge #7780: [0.12] Disable bad-chain alert...
 40 2016-04-01 12:17:14	0|GitHub52|[13bitcoin] 15laanwj pushed 2 new commits to 060.12: 02https://github.com/bitcoin/bitcoin/compare/4d035bcc9aa3...c5f94f6584cb
 41 2016-04-01 12:17:14	0|GitHub66|[13bitcoin] 15laanwj closed pull request #7780: [0.12] Disable bad-chain alert (060.12...06spurious) 02https://github.com/bitcoin/bitcoin/pull/7780
 42 2016-04-01 12:40:08	0|GitHub181|[13bitcoin] 15laanwj opened pull request #7781: devtools: Auto-set branch to merge to in github-merge (06master...062016_04_github_merge_autobranch) 02https://github.com/bitcoin/bitcoin/pull/7781
 43 2016-04-01 12:43:02	0|GitHub124|13bitcoin/06master 147539f1a 15Wladimir J. van der Laan: tests: Make proxy_test work on travis servers without IPv6
 44 2016-04-01 12:43:02	0|GitHub124|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/28ad4d9fc2be...e9723cb27384
 45 2016-04-01 12:43:02	0|GitHub179|[13bitcoin] 15laanwj closed pull request #7489: tests: Make proxy_test work on travis servers without IPv6 (06master...062016_02_ipv6_tests_conditional) 02https://github.com/bitcoin/bitcoin/pull/7489
 46 2016-04-01 12:43:03	0|GitHub124|13bitcoin/06master 14e9723cb 15Wladimir J. van der Laan: Merge #7489: tests: Make proxy_test work on travis servers without IPv6...
 47 2016-04-01 15:15:17	0|GitHub3|[13bitcoin] 15jonasschnelli opened pull request #7783: [Qt] RPC-Console: support nested commands and simple value queries (06master...062016/04/qt_console_nested) 02https://github.com/bitcoin/bitcoin/pull/7783
 48 2016-04-01 15:55:00	0|GitHub44|[13bitcoin] 15laanwj closed pull request #7485: Use system univalue by default (06master...06sys_univalue_def) 02https://github.com/bitcoin/bitcoin/pull/7485
 49 2016-04-01 16:00:17	0|GitHub75|[13bitcoin] 15laanwj closed pull request #7464: Opt-in RBF must be strictly enabled or disabled before GBT can be called (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/7464
 50 2016-04-01 16:22:03	0|instagibbs|in TestingSetup constructor, is the coinbaseKey.MakeNewKey stuff to just over-write the true genesis block for testing?
 51 2016-04-01 17:47:25	0|paveljanik|jonasschnelli, do you have Qt5DBus.pc in 5.6?
 52 2016-04-01 18:31:50	0|jonasschnelli|paveljanik: I saw you have found it. Or should I try to locate the file?
 53 2016-04-01 18:32:18	0|paveljanik|jonasschnelli, I generated it 8)
 54 2016-04-01 18:32:30	0|paveljanik|do you have it in your installation?
 55 2016-04-01 18:33:54	0|paveljanik|The official installer has DBus framework...
 56 2016-04-01 19:08:42	0|jonasschnelli|paveljanik: no. no Qt5DBus.pc
 57 2016-04-01 19:08:50	0|jonasschnelli|But also not in 5.5.1
 58 2016-04-01 19:08:58	0|jonasschnelli|maybe not on OSX?
 59 2016-04-01 19:10:01	0|paveljanik|Don't know. There was one in 5.4.
 60 2016-04-01 19:24:55	0|gmaxwell|https://github.com/blog/2141-squash-your-commits but can you turn off both?
 61 2016-04-01 19:27:44	0|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?
 62 2016-04-01 19:28:22	0|jonasschnelli|But my humble net/buffer experience tells me the size must be before the payload in order to work with chunked messages transmitting
 63 2016-04-01 19:29:09	0|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.
 64 2016-04-01 19:30:16	0|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.
 65 2016-04-01 19:30:51	0|sipa|jonasschnelli: the size obviously has to go first!
 66 2016-04-01 19:30:59	0|sipa|jonasschnelli: but the authentication tag goes after
 67 2016-04-01 19:31:09	0|jonasschnelli|Ah. Mixed it up. Right.
 68 2016-04-01 19:31:22	0|jonasschnelli|And the tag has a fixed size. Right.
 69 2016-04-01 19:31:32	0|jonasschnelli|[09:29:02] <gmaxwell> by sending a message in the channel, "everything that follows will be the next key"
 70 2016-04-01 19:31:48	0|jonasschnelli|I also think about the rekeying issue. Do we really need an additional message for that?
 71 2016-04-01 19:32:02	0|jonasschnelli|hmm.. I think so.
 72 2016-04-01 19:33:02	0|jonasschnelli|Or we could reuse the "encinit" message with a 33 zero bytes as pubkey to indicate "a next key".
 73 2016-04-01 19:35:54	0|GitHub128|[13bitcoin] 15instagibbs opened pull request #7784: miner_tests number clarification (06master...06patch-4) 02https://github.com/bitcoin/bitcoin/pull/7784
 74 2016-04-01 19:37:43	0|GitHub151|[13bitcoin] 15paveljanik opened pull request #7785: Trivial: Fix typo: Optimizaton -> Optimization [skip ci] (06master...06patch-16) 02https://github.com/bitcoin/bitcoin/pull/7785
 75 2016-04-01 19:41:39	0|btcdrak|gmaxwell: no, you have to choose one https://usercontent.irccloud-cdn.com/file/mf5sjbnQ/screenshot-github.com%202016-04-01%2020-41-08.png
 76 2016-04-01 19:43:52	0|Arnavion|Why turn both off? Is it that you want to remove the ability to merge from the web page, and only allow it from CLI + push?
 77 2016-04-01 19:45:15	0|MarcoFalke|turning off both would mean auto-rebase, I assume
 78 2016-04-01 19:45:55	0|jonasschnelli|btcdrak: we do not merge with github, right?
 79 2016-04-01 19:45:57	0|MarcoFalke|I am wondering who is the author of the squash commit?
 80 2016-04-01 19:46:02	0|MarcoFalke|no we don't
 81 2016-04-01 19:46:06	0|gmaxwell|Arnavion: correct. Some projects, like bitcoin core forbid webpage merges by procedure.
 82 2016-04-01 19:46:12	0|Arnavion|Yeah
 83 2016-04-01 19:46:15	0|jonasschnelli|MarcoFalke: the merger.
 84 2016-04-01 19:46:37	0|jonasschnelli|Arnavion: Github merges are not GPG signed.
 85 2016-04-01 19:46:54	0|Arnavion|I don't know if GH will want to put in an option to reduce the functionality of their website, heh
 86 2016-04-01 19:46:56	0|jonasschnelli|Github could smuggle in a MAX_BLOCKSIZE change. :)
 87 2016-04-01 19:47:50	0|jonasschnelli|sipa gmaxwell: Is it relevant to hash(old_session_id) the session-id during re-keying?
 88 2016-04-01 19:48:05	0|btcdrak|gmaxwell: "merge by webpage", you make it sound so dirty!
 89 2016-04-01 19:48:10	0|btcdrak|:)
 90 2016-04-01 19:48:13	0|MarcoFalke|Is there an "emergency plan" ready in case somone hit's the GitHub merge button by accident :) ?
 91 2016-04-01 19:48:26	0|jonasschnelli|MarcoFalke: I think its disabled.
 92 2016-04-01 19:49:01	0|gmaxwell|AFAIK it's not because there is no way to do so.
 93 2016-04-01 20:42:22	0|cfields|github also allows you to disable a merge until tests have passed
 94 2016-04-01 20:42:36	0|cfields|so at least a MAX_BLOCKSIZE would have to fix the unit tests as well :p
 95 2016-04-01 20:42:49	0|cfields|*MAX_BLOCKSIZE change
 96 2016-04-01 20:48:20	0|jonasschnelli|kanzure: If you have time, I need a native english to fix the enc/auth BIPs. https://github.com/bitcoin/bips/pull/362/files
 97 2016-04-01 20:49:01	0|jonasschnelli|Its not final but a clean language/grammar would be good at this point.
 98 2016-04-01 20:49:21	0|jonasschnelli|(can also be any other volunteer)
 99 2016-04-01 20:50:35	0|jonasschnelli|Can directly be PRed (no I'm getting impudent) https://github.com/jonasschnelli/bips/commits/2016/03/auth_enc2
100 2016-04-01 21:45:07	0|GitHub5|[13bitcoin] 15s-matthew-english opened pull request #7786: Update policy.cpp (06master...06patch-2) 02https://github.com/bitcoin/bitcoin/pull/7786
101 2016-04-01 22:24:45	0|kanzure|jonasschnelli: so basic rewrite keep meaning the same?
102 2016-04-01 22:25:07	0|kanzure|i will look at this.