1 2017-03-14 06:27:57	0|wumpus|luke-jr: that would be a great idea
  2 2017-03-14 06:28:15	0|wumpus|luke-jr: jeremyrubin was also talking about that, it's pretty hard to do in practice, though
  3 2017-03-14 06:28:18	0|wumpus|jonasschnelli: my mac just arrived, so I'll hopefully be able to help with macosx releases and development now, too
  4 2017-03-14 06:36:23	0|warren|brg444: it just occurred to me that optimizations beyond validation performance have helped core deal with larger block sizes up to 1MB. Do you already have the few cases where the performance of `getblocktemplate` was dramatically improved in the context of a huge mempool? That became slow at some point, and fear of orphans from it being slow also contributed to centralization pressure.
  5 2017-03-14 06:38:44	0|bitcoin-git|13bitcoin/06master 14a327e8e 15Wladimir J. van der Laan: devtools: Make github-merge compute SHA512 from git, instead of worktree...
  6 2017-03-14 06:38:44	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/8040ae6fc576...cce056d72918
  7 2017-03-14 06:38:45	0|bitcoin-git|13bitcoin/06master 14cce056d 15Wladimir J. van der Laan: Merge #9984: devtools: Make github-merge compute SHA512 from git, instead of worktree...
  8 2017-03-14 06:39:04	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9984: devtools: Make github-merge compute SHA512 from git, instead of worktree (06master...062017_03_merge_hash_git) 02https://github.com/bitcoin/bitcoin/pull/9984
  9 2017-03-14 06:43:48	0|jeremyrubin|luke-jr: there are some nice ways to effectively recover, the key is to make the bad_alloc handler rentrant-safe (it's not right now) and then try to flush some caches, or even just wait a split second in hopes that another thread frees whatever large allocation it made.
 10 2017-03-14 06:44:22	0|jeremyrubin|I have some notes somewhere on some of the various things that could be done. if you're interested, email me
 11 2017-03-14 06:44:40	0|luke-jr|I suppose the bigger problem will be overcommitments
 12 2017-03-14 06:48:21	0|gmaxwell|luke-jr: you can do virtually nothing without more allocations happening, you certantly can't flush the dbcache.
 13 2017-03-14 06:48:30	0|gmaxwell|maybe you could drop the mempool completely.
 14 2017-03-14 06:48:56	0|gmaxwell|but its unlikely that you caught the exception at a point you could continue from.
 15 2017-03-14 06:52:05	0|jeremyrubin|so one idea i had
 16 2017-03-14 06:52:18	0|jeremyrubin|is to have 10MB as a "break in case of emergency" memeory
 17 2017-03-14 06:52:22	0|jeremyrubin|so when you OOM
 18 2017-03-14 06:52:24	0|jeremyrubin|you free that
 19 2017-03-14 06:52:28	0|jeremyrubin|and then try to flush
 20 2017-03-14 06:53:37	0|midnightmagic|That seems to be a single entity, by the way, joining and leaving with all those usernames and IP addresses.
 21 2017-03-14 07:13:52	0|wumpus|gmaxwell: after an exception it is hard to recover, the idea of set_new_handler is to handle out-of-memory errors before an exception happens; "make more memory available" is an explicit goal of it
 22 2017-03-14 07:13:57	0|wumpus|e.g. http://en.cppreference.com/w/cpp/memory/new/set_new_handler
 23 2017-03-14 07:14:21	0|wumpus|so it will call that on allocation, if it notices no memory is available
 24 2017-03-14 07:14:48	0|sipa|wumpus: so, it seems part of our oom prblems are due to the fact that the writebatch in peveldb is allocated as one continuous region
 25 2017-03-14 07:14:56	0|sipa|*leveldb
 26 2017-03-14 07:15:05	0|wumpus|it's exactly designed to be able to flush caches and such, though getting the locking etc. straight is a challenge
 27 2017-03-14 07:15:51	0|wumpus|sipa: yes the batches are huge in memory
 28 2017-03-14 07:16:20	0|sipa|but from a casual look, it's just an std::string in memory that gets appended over and iterated over
 29 2017-03-14 07:16:35	0|sipa|i.e., nothing a linked list of blobs can't do
 30 2017-03-14 07:16:53	0|wumpus|right, a deque or such
 31 2017-03-14 07:17:20	0|wumpus|dividing it up is a good idea, would also avoid copying while resizing, blobs shouldn't be too small to avoid this resulting in more overhead
 32 2017-03-14 07:18:08	0|sipa|i was thinking 1 MB as blob size
 33 2017-03-14 07:18:24	0|wumpus|yes something of that order
 34 2017-03-14 07:19:02	0|wumpus|a serious number but not enough to run into address space fragmentation issues on 32 bit
 35 2017-03-14 07:19:50	0|jonasschnelli|wumpus: A Mac?! Will it be your main workstation? :-)
 36 2017-03-14 07:20:05	0|wumpus|it'd be a great improvement from using strings... that always bothered me too
 37 2017-03-14 07:20:15	0|wumpus|jonasschnelli: hah, probably not, I have to chase my gf away from it first :p
 38 2017-03-14 07:20:25	0|jonasschnelli|hehe...
 39 2017-03-14 07:22:19	0|wumpus|sipa: I actually have very little problem with improving leveldb to be a better database for our specific usecase; it seems upstream development is kind of dormant anyway, though you could always try to upstream things ofcourse
 40 2017-03-14 07:23:48	0|wumpus|but the more this UTXO set grows the less likely is that an off the shelf database library just provides what we need. And leveldb seems a good starting point in any case, it worked better for our use case than anything else I tried
 41 2017-03-14 07:24:02	0|sipa|wumpus: right
 42 2017-03-14 07:24:22	0|sipa|utxo size growth is an unsolvable problem except using txo/mmr trees
 43 2017-03-14 07:25:13	0|sipa|though consensus rules that punish growth may go a long way
 44 2017-03-14 07:26:37	0|wumpus|that would be solving the problem at the source, yes
 45 2017-03-14 07:27:26	0|wumpus|in any case we could do a 0.14.1 that reduces default memory requirements
 46 2017-03-14 07:27:49	0|wumpus|then in 0.15 try to improve memory handling at large
 47 2017-03-14 07:28:47	0|sipa|how fast do we want a 0.14.1?
 48 2017-03-14 07:29:30	0|gmaxwell|wumpus: ah, indeed if you can catch it before the exception, thats at least somewhat interesting.
 49 2017-03-14 07:30:56	0|warren|I personally have always been sad we have been unable to bend down the growth curve of UTXO expansion by realigning the relative cost of UTXO creation.  I am aware and appreciative of how segwit mitigates this problem a bit by reducing the cost to spend a UTXO.  But sadly that is only effective for the legitimate UTXO ... there are plenty of questionable other UTXO that may never be spent.   Runaway growth of UTXO expansion for data storage
 50 2017-03-14 07:30:56	0|warren|is among the worst efficient uses of Bitcoin.  I think a more effective guard against too-cheap UTXO creation leading to such a persistent negative externality in which people use the precious resource inefficient ways would be fix the original design problem.   Maybe change it so fees to create a UTXO are more front-loaded more toward time of creation instead of at the time it is spending?
 51 2017-03-14 07:31:11	0|gmaxwell|I think for 0.14.1 it would be sufficient to twiddle the mempool sharing enough that an 2GB aarch64 device wyncs.
 52 2017-03-14 07:31:11	0|wumpus|sipa: I don't know. All the OOM issues reported seem to point at this being quasi urgent
 53 2017-03-14 07:31:25	0|wumpus|gmaxwell: right - it does it before getting back to the application
 54 2017-03-14 07:32:16	0|gmaxwell|warren: that is exactly what segwit does, increases cost to create while decreasing cost to consume; assuming constant relative load.
 55 2017-03-14 07:32:47	0|warren|gmaxwell: which mostly works, except what of the cheap-to-create utxo that didn't have the goal of being spent?
 56 2017-03-14 07:32:54	0|sipa|gmaxwell: i'm not sure that making dbcache borrow only 50% of the free mempool space... i'm not sure that's enough to make the odroid-c2 sync out of the box
 57 2017-03-14 07:33:00	0|sipa|but i haven't tried
 58 2017-03-14 07:33:30	0|gmaxwell|warren: it was made more expensive.
 59 2017-03-14 07:35:15	0|warren|I might have missed something ... how?
 60 2017-03-14 07:35:35	0|gmaxwell|...
 61 2017-03-14 07:36:13	0|gmaxwell|Because it is exclusively non-witness data, and under constant relative load non-witness data is several times more expensive than witness data.
 62 2017-03-14 07:39:27	0|jeremyrubin|I have a feeling that theres a bunch of small things that could be refactored to save a MB here or there. I know there are a couple places where queues are pushed/popped without actually freeing the space in the vector later. I think if 0.14.1 is going to have a memory goal, a lot of headway can be made with a bunch of small things that require less review.
 63 2017-03-14 07:39:47	0|gmaxwell|no.
 64 2017-03-14 07:40:04	0|gmaxwell|0.14.1 is a bugfix release it will not get a pile of little MB shaving changes.
 65 2017-03-14 07:41:16	0|wumpus|that would be for 0.15
 66 2017-03-14 07:41:21	0|gmaxwell|ya.
 67 2017-03-14 07:41:55	0|gmaxwell|it might pick up a single blunt fix to prevent IBD from failing on 2GB hosts... sure. but I think thats all thats interesting for a backport.
 68 2017-03-14 07:42:56	0|jeremyrubin|ah ok I misunderstood what "in any case we could do a 0.14.1 that reduces default memory requirements" meant
 69 2017-03-14 07:43:17	0|jeremyrubin|you just mean the parameters?
 70 2017-03-14 07:43:23	0|gmaxwell|jeremyrubin: because of fragmentation shrinking those vectors often doesn't reduce memory usage-- though fine enough to do so if we're actually done with them.
 71 2017-03-14 07:43:54	0|jeremyrubin|gmaxwell: yeah these are ones that are done with, freeing them won't worsen fragmentation
 72 2017-03-14 07:44:27	0|gmaxwell|yea, won't worsen but due to it may not reduce usage. Still good to do. Don't get your hopes up too much, we suffer badly from fragmentation.
 73 2017-03-14 07:45:04	0|wumpus|parameters, or small tweaking, anything that is sure to fix the "IBD crashes on 1GB/2GB ARM boards by default" issue
 74 2017-03-14 07:46:52	0|jeremyrubin|There's at least one that is at most 4MB that is held permanently, never could be resized, that could be released when not used.
 75 2017-03-14 07:47:06	0|jeremyrubin|*never is resized/freed
 76 2017-03-14 07:48:02	0|jeremyrubin|There are a couple things I think might be similar, but I need to actually measure what their max loads are
 77 2017-03-14 07:48:37	0|gmaxwell|well if you can add up to the several hundred megs of overage that we have, that would be nice. :P
 78 2017-03-14 08:25:38	0|wumpus|even someone with 4GB reporting OOM crash issues
 79 2017-03-14 08:25:40	0|wumpus|https://github.com/bitcoin/bitcoin/issues/9969#issuecomment-286207333
 80 2017-03-14 08:25:44	0|wumpus|windows tho, but still
 81 2017-03-14 08:26:16	0|wumpus|windows 32 bit even, err yea, the amount of memory can be safely ignored I guess..
 82 2017-03-14 08:26:34	0|rabidus_|:D
 83 2017-03-14 08:26:44	0|gmaxwell|likely virt more of an issue than actual usage...
 84 2017-03-14 08:27:08	0|wumpus|IIRC windows 32 bit virtual memory use is terrible, even worse than linux 32-bit usage
 85 2017-03-14 08:27:21	0|wumpus|exactly
 86 2017-03-14 08:31:08	0|wumpus|ah yes: split is 2GB/2GB between kernel/user on windows by default, 3GB/1GB on linux (most distros), although on both OSes it is configurable in some way
 87 2017-03-14 08:32:40	0|wumpus|this might actually help some users: https://knowledge.autodesk.com/support/autocad/troubleshooting/caas/sfdcarticles/sfdcarticles/How-to-enable-a-3GB-switch-on-Windows-Vista-Windows-7-or-Windows-XP-s.html
 88 2017-03-14 09:05:59	0|bitcoin-git|[13bitcoin] 15NicolasDorier opened pull request #9989: [Doc] Removing references to Windows 32 bit from README (06master...06patch-2) 02https://github.com/bitcoin/bitcoin/pull/9989
 89 2017-03-14 09:06:32	0|bitcoin-git|[13bitcoin] 15Rav3nPL opened pull request #9990: Merge pull request #1 from bitpay/master (060.14...06master) 02https://github.com/bitcoin/bitcoin/pull/9990
 90 2017-03-14 09:07:05	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #9990: Merge pull request #1 from bitpay/master (060.14...06master) 02https://github.com/bitcoin/bitcoin/pull/9990
 91 2017-03-14 09:15:33	0|bitcoin-git|13bitcoin/06master 14655df06 15Suhas Daftuar: QA: getblocktemplate_longpoll.py should always use >0 fee tx
 92 2017-03-14 09:15:33	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/cce056d72918...857d1e171e05
 93 2017-03-14 09:15:34	0|bitcoin-git|13bitcoin/06master 14857d1e1 15MarcoFalke: Merge #9977: QA: getblocktemplate_longpoll.py should always use >0 fee tx...
 94 2017-03-14 09:15:52	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9977: QA: getblocktemplate_longpoll.py should always use >0 fee tx (06master...062017-03-gbt-longpoll-test) 02https://github.com/bitcoin/bitcoin/pull/9977
 95 2017-03-14 09:38:55	0|bitcoin-git|[13bitcoin] 15laanwj pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/857d1e171e05...1b046603b30e
 96 2017-03-14 09:38:57	0|bitcoin-git|13bitcoin/06master 14972714c 15Daniel Cousens: pow: GetNextWorkRequired never called with NULL pindexLast
 97 2017-03-14 09:38:57	0|bitcoin-git|13bitcoin/06master 14cc44c8f 15NicolasDorier: ContextualCheckBlockHeader should never have pindexPrev to NULL
 98 2017-03-14 09:38:58	0|bitcoin-git|13bitcoin/06master 144d51e9b 15NicolasDorier: Assert ConnectBlock block and pIndex are the same block
 99 2017-03-14 09:41:30	0|bitcoin-git|[13bitcoin] 15NicolasDorier closed pull request #9989: [Doc] Removing references to Windows 32 bit from README (06master...06patch-2) 02https://github.com/bitcoin/bitcoin/pull/9989
100 2017-03-14 09:43:31	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/1b046603b30e...67ed40ed82c6
101 2017-03-14 09:43:32	0|bitcoin-git|13bitcoin/06master 1445a5aaf 15Jeremy Rubin: Only call clear on prevector if it isn't trivially destructible and don't loop in clear
102 2017-03-14 09:43:32	0|bitcoin-git|13bitcoin/06master 14aaa02e7 15Jeremy Rubin: Add prevector destructor benchmark
103 2017-03-14 09:43:33	0|bitcoin-git|13bitcoin/06master 1467ed40e 15Wladimir J. van der Laan: Merge #9505: Prevector Quick Destruct...
104 2017-03-14 09:43:45	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9505: Prevector Quick Destruct (06master...06prevector-quick-destruct) 02https://github.com/bitcoin/bitcoin/pull/9505
105 2017-03-14 10:22:05	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/67ed40ed82c6...3cc13eac40a0
106 2017-03-14 10:22:06	0|bitcoin-git|13bitcoin/06master 141269b8a 15Suhas Daftuar: Fix logging bug and improve readability of smartfees.py
107 2017-03-14 10:22:06	0|bitcoin-git|13bitcoin/06master 14b9f34e8 15Suhas Daftuar: Improve readability of segwit.py
108 2017-03-14 10:22:07	0|bitcoin-git|13bitcoin/06master 143cc13ea 15Wladimir J. van der Laan: Merge #9970: Improve readability of segwit.py, smartfees.py...
109 2017-03-14 10:22:21	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9970: Improve readability of segwit.py, smartfees.py (06master...062017-03-segwit-test-improvements) 02https://github.com/bitcoin/bitcoin/pull/9970
110 2017-03-14 10:23:28	0|wumpus|cfields: any opinion on https://github.com/bitcoin/bitcoin/pull/9921?
111 2017-03-14 10:24:50	0|luke-jr|why is SOCKET unsigned anyway?
112 2017-03-14 10:25:44	0|wumpus|luke-jr: because it is on windows
113 2017-03-14 10:26:09	0|luke-jr|no?
114 2017-03-14 10:26:17	0|luke-jr|#ifndef WIN32
115 2017-03-14 10:26:19	0|luke-jr|#define MSG_DONTWAIT        0		 +typedef unsigned int SOCKET;
116 2017-03-14 10:26:19	0|wumpus|if I were to design something like this I'd just use int for fds, as that's what all the UNIXes have, but someone coming from windows would use unsigned types
117 2017-03-14 10:26:27	0|wumpus|SOCKET is a standard type on win32
118 2017-03-14 10:26:31	0|wumpus|which is an unsigned int
119 2017-03-14 10:26:33	0|luke-jr|yes, but this is ifNdef WIN32
120 2017-03-14 10:27:03	0|wumpus|I know, but defining it as signed on unix would be confusing
121 2017-03-14 10:27:20	0|wumpus|as all the socket handling code is written to handle unsigned integers
122 2017-03-14 10:27:30	0|luke-jr|weird.
123 2017-03-14 10:27:39	0|wumpus|I hope most of this can go away once the P2P code is switched to libevent
124 2017-03-14 10:28:01	0|luke-jr|is that going to finally be in 0.15? or maybe I should reopen the libevent-optional PR :p
125 2017-03-14 10:28:17	0|wumpus|I hope so.
126 2017-03-14 10:32:56	0|wumpus|anyhow if "we're going to nuke all of this and replace it with libevent soon" is the reason to not merge #9921 I'd be happy, but if that's going to take a while it's somewhat useful to me
127 2017-03-14 10:32:57	0|gribble|https://github.com/bitcoin/bitcoin/issues/9921 | build: Probe MSG_DONTWAIT in the same way as MSG_NOSIGNAL by laanwj · Pull Request #9921 · bitcoin/bitcoin · GitHub
128 2017-03-14 10:33:09	0|wumpus|and it's not like it is a huge risky change...\
129 2017-03-14 11:24:08	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/3cc13eac40a0...2c781fb92026
130 2017-03-14 11:24:09	0|bitcoin-git|13bitcoin/06master 1496c7f2c 15Jeremy Rubin: Add CheckQueue Tests
131 2017-03-14 11:24:09	0|bitcoin-git|13bitcoin/06master 14e207342 15Jeremy Rubin: Fix CCheckQueue IsIdle (potential) race condition and remove dangerous constructors.
132 2017-03-14 11:24:10	0|bitcoin-git|13bitcoin/06master 142c781fb 15Wladimir J. van der Laan: Merge #9497: CCheckQueue Unit Tests...
133 2017-03-14 11:24:23	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9497: CCheckQueue Unit Tests (06master...06checkqueue-tests) 02https://github.com/bitcoin/bitcoin/pull/9497
134 2017-03-14 11:56:26	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/2c781fb92026...416809c11b82
135 2017-03-14 11:56:27	0|bitcoin-git|13bitcoin/06master 14abe7b3d 15Suhas Daftuar: Don't require segwit in getblocktemplate for segwit signalling or mining...
136 2017-03-14 11:56:27	0|bitcoin-git|13bitcoin/06master 14c85ffe6 15Suhas Daftuar: Test transaction selection when gbt called without segwit support
137 2017-03-14 11:56:28	0|bitcoin-git|13bitcoin/06master 14416809c 15Wladimir J. van der Laan: Merge #9955: Don't require segwit in getblocktemplate for segwit signalling or mining...
138 2017-03-14 11:56:46	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9955: Don't require segwit in getblocktemplate for segwit signalling or mining (06master...062017-03-mining-segwit-changes) 02https://github.com/bitcoin/bitcoin/pull/9955
139 2017-03-14 12:07:08	0|bitcoin-git|[13bitcoin] 15laanwj pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/416809c11b82...ce01e6226ce5
140 2017-03-14 12:07:09	0|bitcoin-git|13bitcoin/06master 143e4d7bf 15Luke Dashjr: Qt/Send: Figure a decent warning colour from theme
141 2017-03-14 12:07:09	0|bitcoin-git|13bitcoin/06master 14c5adf8f 15Jonas Schnelli: [Qt] Show more significant warning if we fall back to the default fee
142 2017-03-14 12:07:10	0|bitcoin-git|13bitcoin/06master 147abe7bb 15Luke Dashjr: Qt/Send: Give fallback fee a reasonable indent
143 2017-03-14 12:07:18	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9481: [Qt] Show more significant warning if we fall back to the default fee (06master...062017/01/fee_warning) 02https://github.com/bitcoin/bitcoin/pull/9481
144 2017-03-14 13:23:49	0|bitcoin-git|[13bitcoin] 15NicolasDorier opened pull request #9991: listreceivedbyaddress Filter Address (06master...06listreceivedbyaddress-filtered) 02https://github.com/bitcoin/bitcoin/pull/9991
145 2017-03-14 14:11:46	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9503: listreceivedbyaddress Filter Address (06master...06listreceivedbyaddress-filtered) 02https://github.com/bitcoin/bitcoin/pull/9503
146 2017-03-14 15:40:03	0|afk11_|could someone get me the raw block hex for 000000000066757b6b59f9a18b1021f160e48f0f75211800961c4fe2535acd7f - pm please
147 2017-03-14 15:40:08	0|afk11_|(on testnet)
148 2017-03-14 15:45:44	0|nemgun|one minut
149 2017-03-14 15:48:45	0|afk11_|thanks. your node version would interest me as well
150 2017-03-14 15:49:57	0|nemgun|i use an api
151 2017-03-14 15:50:24	0|nemgun|webbtc.com says the block doesn't exists
152 2017-03-14 15:52:45	0|sipa|afk11_: i onoy have the header
153 2017-03-14 15:54:42	0|sipa|*only
154 2017-03-14 15:57:38	0|Victorsueca|afk11_: still need it?
155 2017-03-14 16:14:12	0|afk11_|my segwit node has something different for that height. its currently on 1093617, but v0.12 explorers are on 1093623. the last block I have in common with them is 00000000000000ebf174a2ccaaf2024baadba5cef04862d2ce261097c574f712
156 2017-03-14 16:14:29	0|afk11_|which is 1093555
157 2017-03-14 16:15:46	0|Victorsueca|yeah, I think testnet got hard-forked at some point around that
158 2017-03-14 16:16:17	0|nemgun1|Victorsueca, didn't heard of a testnet hard fork
159 2017-03-14 16:16:20	0|afk11_|looking for a reject message or something
160 2017-03-14 16:18:24	0|Victorsueca|I don't remember well but I think bitcoin classic got to hard-fork on testnet
161 2017-03-14 16:23:53	0|nemgun1|Victorsueca, bitcoin classic is annother coin no ?
162 2017-03-14 16:26:14	0|Victorsueca|it's a hard-fork that replaces the rule that says blocks can't be more than 1MB for one that says blocks can be up to 2MB
163 2017-03-14 16:27:10	0|nemgun1|ah
164 2017-03-14 17:51:56	0|tb302|Hello, is there a possibility at electrum to receive a notification when a payment is received?
165 2017-03-14 17:52:46	0|achow101|tb302: this channel is for bitcoin core, not electrum
166 2017-03-14 17:53:14	0|tb302|oh sry, is there a channel for electrum?
167 2017-03-14 17:53:52	0|achow101|probably #electrum
168 2017-03-14 22:48:13	0|bitcoin-git|[13bitcoin] 15antron3000 opened pull request #9992: Update amount.h (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/9992
169 2017-03-14 22:49:08	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #9992: Update amount.h (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/9992
170 2017-03-14 22:53:10	0|bitcoin-git|[13bitcoin] 15pstratem opened pull request #9993: Initialize nRelockTime (06master...062017-03-14-cwallet-nrelocktime-init) 02https://github.com/bitcoin/bitcoin/pull/9993
171 2017-03-14 23:31:35	0|luke-jr|a number of decent BIPs have negative comments; I suggest perhaps people may wish to provide positive feedback to counter them. https://github.com/bitcoin/bips/pull/500
172 2017-03-14 23:37:49	0|gmaxwell|luke-jr: really? thats what you're going to do?
173 2017-03-14 23:37:56	0|gmaxwell|I can't even see what the comments are!
174 2017-03-14 23:38:36	0|gmaxwell|oh it's fucking Voskuil shitting on everything.
175 2017-03-14 23:39:12	0|gmaxwell|no, I think I'll just recommend no one use BIPs for anything. Process has failed.
176 2017-03-14 23:39:17	0|luke-jr|…
177 2017-03-14 23:39:48	0|luke-jr|why can't you see what the comments are? why not leave positive comments?
178 2017-03-14 23:40:58	0|luke-jr|processes may fail if people just give up rather than using them, but we're not quite there yet.
179 2017-03-14 23:47:21	0|gmaxwell|luke-jr: the editor on github is uselessly bad.
180 2017-03-14 23:47:52	0|gmaxwell|luke-jr: because someone who does pratically nothing but shit over anything has a fundimental advantage in this process.
181 2017-03-14 23:48:04	0|gmaxwell|from a position of low reputation they can fling poo all day.
182 2017-03-14 23:48:22	0|luke-jr|could git clone https://github.com/bitcoin/bips.wiki.git if that makes it easier
183 2017-03-14 23:48:58	0|luke-jr|although I personally don't see a problem with github's editor
184 2017-03-14 23:54:27	0|TD-Linux|how do I see the comments?