1 2017-12-14 01:26:23	0|Nobody_|Please update Satoshi Nakamoto & The Bitcoin Core Developers that the Blockchain is complete and Copyright Free for this Holiday Season
  2 2017-12-14 01:26:43	0|Nobody_|I will not reveil my Identity but things work in wonderful ways
  3 2017-12-14 01:27:13	0|promag|nice, ty
  4 2017-12-14 01:27:15	0|Nobody_|Here is for those group(s) and anyone who made a Cryptocurrency, never having to worry about it not being protected
  5 2017-12-14 01:27:23	0|Nobody_|Blockchain  ECDSA Public Key (Bitcoin Compatible):  15oZ3FrhQJsVnpT6Ho1ZrQFQRnaaZF9gdS exists since Wed Oct 11 2017 19:09:57 GMT-0700 (Pacific Summer Time)   Hash (In HEX)  SHA3-384 23b81d863e9607f3416d14cb5913ee4e83cc7bf32ae3a6fab12c53e741ac7dda028c3dcc1d25950bb2f1122cacba10ba  SHA3-512 cc7240e11c025e2411630ba97e2e7cf59aa684823a147d1a3972d7b4eaf3019af7d8c25dcb25a6c25cd7b5b9b7f72c944b0fd6e7bda4aa365f036cc4a188fc65   HMAC (In
  6 2017-12-14 01:27:35	0|Nobody_|magnet:?xt=urn:btih:0539a6634c7f87f17788767b3a3c250ddaa4cde2&dn=Blockchain+updated.txt&tr=wss%3A%2F%2Ftracker.btorrent.xyz&tr=wss%3A%2F%2Ftracker.fastcast.nz&tr=wss%3A%2F%2Ftracker.openwebtorrent.com
  7 2017-12-14 01:27:50	0|Nobody_|Hash: 0539a6634c7f87f17788767b3a3c250ddaa4cde2
  8 2017-12-14 01:28:22	0|Nobody_|HMAC (In HEX)  Encrypted SHA3-384 00bed720e4ecd0897297c5b3f583d9567a19b2e9952c0a40fdd0bf24ae99093cfe27a3b433ca2b964a1a607c0dfb8b91  Encrypted SHA3-512 97013026b80c0a190e3591c42b3a75cce484a420d7f2305c28d6a1a7a937229d49aab88cb4d5aa90548df98eda2b699007bb5fae24e2485ec9fb0c0a1e685b41
  9 2017-12-14 01:30:21	0|sipa|Nobody_: i have the impression you're trying to be nice, so i don't want to yell at you, but i have no clue what you're trying to say
 10 2017-12-14 01:31:16	0|Nobody_|I truely am Nobody in the system and as the Court of Japan ruled, Nobody own's the Cryptocurrency as Nobody own's the Blockchain so enjoy your holiday ok? make it the Perfect Greatest you ever could have! ;)
 11 2017-12-14 01:31:25	0|Nobody_|With even a bit of love from God
 12 2017-12-14 01:31:28	0|Nobody_|No Joke!
 13 2017-12-14 01:31:34	0|sipa|ok, thank you!
 14 2017-12-14 01:31:35	0|Nobody_|Hahaha
 15 2017-12-14 01:31:57	0|Nobody_|Time to leave, have a great one and that magnet link will download if you need it
 16 2017-12-14 01:32:05	0|Nobody_|https://btorrent.xyz/#0539a6634c7f87f17788767b3a3c250ddaa4cde2
 17 2017-12-14 01:32:07	0|gribble|https://github.com/bitcoin/bitcoin/issues/0539 | Qt GUI updates by laanwj · Pull Request #539 · bitcoin/bitcoin · GitHub
 18 2017-12-14 01:32:11	0|Nobody_|blob:https://btorrent.xyz/427f6751-7950-476d-84a3-693924bb02bc
 19 2017-12-14 01:32:25	0|sipa|please don't expect people to download things from random lins
 20 2017-12-14 01:33:01	0|Nobody_|Time to leave, please as we already added the Faucet in the Bitcoin Core make sure it is finalized
 21 2017-12-14 01:33:15	0|Nobody_|it is crutial for the Robot's to request from Nobody
 22 2017-12-14 01:33:50	0|Nobody_|it is a Free Faucet that you can deposit, withdraw or transact to a Nobody account in the Core that allow's for a Savings like Wallet
 23 2017-12-14 01:33:53	0|mryandao|quick question: does bitcoin 0.7.0rc3 also build a qt GUI interface?
 24 2017-12-14 01:33:55	0|Nobody_|for Everyone to use
 25 2017-12-14 01:34:14	0|sipa|mryandao: you certainly can
 26 2017-12-14 01:34:19	0|Nobody_|Other than that, Ten Four, Over and Out!
 27 2017-12-14 01:34:19	0|sipa|mryandao: Qt GUI was added in 0.5.0
 28 2017-12-14 01:34:30	0|mryandao|can we also ban the spammer.
 29 2017-12-14 01:34:34	0|mryandao|oh, he left.
 30 2017-12-14 01:37:51	0|jimpo|Is there is a way to see debug logs generated during tests? And even better in tests running on Travis?
 31 2017-12-14 01:39:13	0|sipa|you can call the functional tests .py file with an argument to not clean up the testdir
 32 2017-12-14 01:39:31	0|sipa|--nocleanup
 33 2017-12-14 01:39:59	0|jimpo|For unit tests
 34 2017-12-14 01:40:29	0|jimpo|stdout seems to be suppressed
 35 2017-12-14 01:46:07	0|xmsx|Quick question -- can I import P2SH-P2WPKH address using importmulti?
 36 2017-12-14 01:46:19	0|sipa|no
 37 2017-12-14 01:46:44	0|xmsx|What RPC should I use for it?
 38 2017-12-14 01:47:00	0|sipa|import the private key however you want, and then call addwitnessaddress
 39 2017-12-14 01:47:21	0|sipa|the wallet just doesn't support segwit addresses natively yet
 40 2017-12-14 01:47:21	0|xmsx|addwitnessaddress doesn't rescan the blockchain :'(
 41 2017-12-14 01:47:37	0|sipa|you can call rescanblockchain manually
 42 2017-12-14 01:48:03	0|sipa|not saying all of this is ideal; none of it should be necessary (and soon won't)
 43 2017-12-14 01:49:38	0|xmsx|So we'll be able to use importmulti for segwit soon?
 44 2017-12-14 01:50:04	0|xmsx|Atm it imports the address as watch only :(
 45 2017-12-14 01:50:16	0|sipa|yes
 46 2017-12-14 01:50:20	0|sipa|next release
 47 2017-12-14 01:50:33	0|sipa|(with high probability; unexpected events can always change release plans)
 48 2017-12-14 01:50:47	0|xmsx|Yay, any ETA by any chance?
 49 2017-12-14 01:51:01	0|sipa|no
 50 2017-12-14 01:51:48	0|xmsx|Nvm, thanks a lot for your hard work anyway :)
 51 2017-12-14 01:52:26	0|sipa|thanks!
 52 2017-12-14 01:55:08	0|xmsx|Another question from newb -- is there a way to find out the block height by timestamp?:)
 53 2017-12-14 02:18:28	0|promag|xmsx: iirc no
 54 2017-12-14 02:56:55	0|promag|how long 'make -j5 check VERBOSE=1' usually takes on your machine? anyone?
 55 2017-12-14 02:59:11	0|sipa|from scratch? with ccache?
 56 2017-12-14 02:59:52	0|promag|from scratch? without ccache..
 57 2017-12-14 03:02:01	0|xmsx|Do I have to use Bech32, or using P2SH-P2WPKH is ok for now?
 58 2017-12-14 03:03:59	0|luke-jr|xmsx: you don't have to use anything. you can even use p2pk if you really want to.
 59 2017-12-14 03:05:19	0|xmsx|I really want to stay on bleeding edge :D
 60 2017-12-14 03:05:28	0|sipa|xmsx: at this point, the bitcoin core wallet does not fully support segwit - you can use the addwitnessaddress approach at your own risk
 61 2017-12-14 03:05:49	0|luke-jr|xmsx: well then you should just use Lightning :p
 62 2017-12-14 03:05:57	0|sipa|if you want bleeding edge, try running with https://github.com/bitcoin/bitcoin/pull/11403
 63 2017-12-14 03:06:37	0|sipa|promag: benchmarking
 64 2017-12-14 03:06:49	0|promag|sipa: ah thanks
 65 2017-12-14 03:07:25	0|promag|sipa: but it turns out I had a deadlock
 66 2017-12-14 03:07:37	0|sipa|what do you want? a 4-core i7 system, an 8-core AMD Ryzen, or a 14-core Xeon v3?
 67 2017-12-14 03:08:04	0|luke-jr|16-core POWER9 system? <.<
 68 2017-12-14 03:08:08	0|xmsx|What's the best software for LN? should I use eclair?
 69 2017-12-14 03:08:22	0|promag|heh i5
 70 2017-12-14 03:08:23	0|luke-jr|xmsx: if you're not *writing* software, you should really be asking in #bitcoin
 71 2017-12-14 03:08:38	0|promag|luke-jr: sup?
 72 2017-12-14 03:08:43	0|luke-jr|promag: ?
 73 2017-12-14 03:08:47	0|promag|luke-jr: multiwallet gui :D
 74 2017-12-14 03:09:02	0|luke-jr|sorry, tied up with high priority RL stuff lately :/
 75 2017-12-14 03:09:11	0|xmsx|I'm a backend developer, so I am kinda writing stuff :)
 76 2017-12-14 03:09:12	0|luke-jr|maybe I'll take a break and update multiwallet gui..
 77 2017-12-14 03:09:19	0|promag|np +1
 78 2017-12-14 03:09:33	0|sipa|xmsx: right, but this channel is about bitcoin core's development
 79 2017-12-14 03:09:47	0|sipa|you're welcome to ask here how things work, or discuss related things
 80 2017-12-14 03:09:57	0|sipa|but questions about usage really don't belong here
 81 2017-12-14 03:10:20	0|xmsx|Kk, got it, thanks :)
 82 2017-12-14 03:12:01	0|sipa|promag: on 8-core AMD Ryzen:
 83 2017-12-14 03:12:02	0|sipa|real    3m28.787s
 84 2017-12-14 03:12:02	0|sipa|user    43m10.276s
 85 2017-12-14 03:13:00	0|promag|thanks
 86 2017-12-14 03:35:10	0|luke-jr|k, #11383 rebased & comments addressed
 87 2017-12-14 03:35:12	0|gribble|https://github.com/bitcoin/bitcoin/issues/11383 | Basic Multiwallet GUI support by luke-jr · Pull Request #11383 · bitcoin/bitcoin · GitHub
 88 2017-12-14 03:36:50	0|promag|is fee estimation an activity? like it should show up in the activity window while it's not ready?
 89 2017-12-14 03:37:02	0|promag|luke-jr: k
 90 2017-12-14 03:38:15	0|sipa|promag: that's maybe a useful way to present it
 91 2017-12-14 03:38:37	0|sipa|though it's not actually acitivity as in doing something - it just needs enough data
 92 2017-12-14 03:38:48	0|sipa|so perhaps you can call it 'gather data for fee estimation'
 93 2017-12-14 03:38:52	0|promag|waiting is an activity :D
 94 2017-12-14 03:39:04	0|promag|or that
 95 2017-12-14 03:40:27	0|promag|I like that
 96 2017-12-14 03:41:44	0|fanquake|I'm going to delete the "help me hard fork bitcoin for $500" comments and lock the threads they've been posted on. Seem to be kind of alt-coin related anyway.
 97 2017-12-14 03:42:07	0|sipa|fanquake: thanks
 98 2017-12-14 06:08:41	0|jonasschnelli|[17:12:01]  <sipa>	promag: on 8-core AMD Ryzen:
 99 2017-12-14 06:08:48	0|jonasschnelli|sipa: you are working on a desktop?
100 2017-12-14 06:10:49	0|sipa|jonasschnelli: via ssh
101 2017-12-14 06:11:31	0|jonasschnelli|sipa: heh... yes. I also use a ssh remote build script when I'm on low battery but high bandwidth.
102 2017-12-14 06:15:13	0|sipa|jonasschnelli: no, i don't generally don't build remotely
103 2017-12-14 06:15:21	0|sipa|i just ssh'ed into my desktop
104 2017-12-14 06:15:26	0|sipa|and compiled there
105 2017-12-14 06:15:36	0|jonasschnelli|Yeah.. makes sense...
106 2017-12-14 06:15:41	0|sipa|usually i build just on my laptop
107 2017-12-14 06:16:19	0|jonasschnelli|compiling is just a battery drainer...
108 2017-12-14 06:18:22	0|sipa|i have a power socket nearby :)
109 2017-12-14 06:29:21	0|jonasschnelli|I think it's a travelers work from non-home location problem. :)
110 2017-12-14 06:49:49	0|_jadeeUnix|.
111 2017-12-14 07:50:07	0|jonasschnelli|luke-jr: a complete UTXO scan with sweepprivkeys takes ~3mins on my machine (mainnet)... is there a nice way to show progress?
112 2017-12-14 07:50:16	0|jonasschnelli|(probably not with RPC)
113 2017-12-14 09:31:22	0|promag|wumpus: I guess #11864 is ready
114 2017-12-14 09:31:23	0|gribble|https://github.com/bitcoin/bitcoin/issues/11864 | Make CWallet::FundTransaction atomic by promag · Pull Request #11864 · bitcoin/bitcoin · GitHub
115 2017-12-14 09:34:55	0|wumpus|thanks, will take a look
116 2017-12-14 09:39:00	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/d4991c0cbb8a...2ae58d5bfb76
117 2017-12-14 09:39:01	0|bitcoin-git|13bitcoin/06master 1403a5dc9 15João Barbosa: [wallet] Make CWallet::FundTransaction atomic
118 2017-12-14 09:39:01	0|bitcoin-git|13bitcoin/06master 1495d4450 15João Barbosa: [wallet] Tidy up CWallet::FundTransaction
119 2017-12-14 09:39:02	0|bitcoin-git|13bitcoin/06master 142ae58d5 15Wladimir J. van der Laan: Merge #11864: Make CWallet::FundTransaction atomic...
120 2017-12-14 09:39:36	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11864: Make CWallet::FundTransaction atomic (06master...062017-12-atomic-fundtransaction) 02https://github.com/bitcoin/bitcoin/pull/11864
121 2017-12-14 10:01:47	0|bitcoin-git|[13bitcoin] 15JavadSM closed pull request #11843: Use python not 'python2' (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/11843
122 2017-12-14 10:06:27	0|bitcoin-git|[13bitcoin] 15JavadSM opened pull request #11895: Moving to python3 (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/11895
123 2017-12-14 10:20:20	0|promag|can I get your attention to #11041 ?
124 2017-12-14 10:20:22	0|gribble|https://github.com/bitcoin/bitcoin/issues/11041 | Add LookupBlockIndex by promag · Pull Request #11041 · bitcoin/bitcoin · GitHub
125 2017-12-14 10:28:06	0|wumpus|sure
126 2017-12-14 10:30:40	0|promag|ty
127 2017-12-14 10:41:22	0|wumpus|promag: you add some lock(cs_main), were these missing before?
128 2017-12-14 10:41:39	0|wumpus|you don't mention any lock bug fixes, which is why I ask
129 2017-12-14 11:25:46	0|promag|wumpus: yes missing locks
130 2017-12-14 11:26:35	0|promag|not sure if all are bugs because some come from the init & load block index etc
131 2017-12-14 11:26:52	0|wumpus|ok, please mention that in the issue, we should mark it as bugfix and not only refactor
132 2017-12-14 11:27:04	0|wumpus|yes the ones in init are probably not so relevant, but there is one in wallet too
133 2017-12-14 11:27:09	0|promag|but FindForkInGlobalIndex I think it's a bug
134 2017-12-14 11:28:42	0|wumpus|good, thanks for finding and fixing
135 2017-12-14 11:50:06	0|JackH|is there a limitation to how many addresses Bitcoin Core can generate for a given wallet? We issue about 500 new addresses per day, some which are used, some which are not, but is there a limit per wallet?
136 2017-12-14 11:51:25	0|wumpus|the software has no limit
137 2017-12-14 11:51:46	0|xmsx|I tested a wallet with 300k addresses once
138 2017-12-14 11:53:11	0|wumpus|at some point you might run into resource issues, things going slower
139 2017-12-14 11:55:22	0|JackH|we thought about 300k actually being where we would see problems
140 2017-12-14 11:55:34	0|JackH|we are soon hitting that
141 2017-12-14 11:55:52	0|JackH|would there be any difference between HD wallets and non HD wallets in terms of speed?
142 2017-12-14 11:56:03	0|wumpus|I'd be more worried about the amount of transactions, not so much the number of keys, keys are small
143 2017-12-14 11:56:33	0|JackH|so about 40% are transactions
144 2017-12-14 11:56:46	0|JackH|meaning roughly 120k transactions are stored right now
145 2017-12-14 11:57:01	0|JackH|do we know the bottleneck?
146 2017-12-14 11:58:03	0|wumpus|bitcoin core's wallet is not optimized for handling huge numbers of transactions, for example it keeps them all in memory, and doesn't at the moment have an utxo index. There has been work in that direction but any help is welcome.
147 2017-12-14 11:59:07	0|wumpus|as for what the limits are for your cpu/amount of memory, try it out on a development machine
148 2017-12-14 12:02:29	0|xmsx|Also, I would suggest discussing these questions from throwaway account (No one really needs to know that you store all addresses in single wallet) :)
149 2017-12-14 12:05:03	0|wumpus|e.g. using regtest, you can generate tons of transactions and blocks in a relatively small time
150 2017-12-14 12:08:42	0|promag|wumpus: JackH: actually the number of addresses has a great impact on performance
151 2017-12-14 12:09:11	0|wumpus|it has an impact on performance, but what he asked is whether there's a limit
152 2017-12-14 12:48:52	0|JackH|we are looking to run multiple daemons as a solution
153 2017-12-14 12:49:06	0|JackH|and retire daemons as they hit performance issues
154 2017-12-14 12:49:13	0|JackH|daemons//wallets
155 2017-12-14 12:56:18	0|kabaum_|Is it possible that there are other yet unknown ways to malleate a signature than the "-S" trick? Or maybe even known ones? I refer only to inherent ECDSA signature malleability.
156 2017-12-14 13:18:02	0|xmsx|Could anyone review changes to segwitsupport.csv (bitcoincore.org repo) please? Using P2SH-P2WPKH addresses atm but will add bech32 soon too :)
157 2017-12-14 13:18:31	0|wumpus|kabaum_: yes that is possible (might be better to ask in #bitcoin-wizards)
158 2017-12-14 13:50:07	0|kabaum_|wumpus: thanks
159 2017-12-14 13:53:14	0|Varunram|promag: http://www.kumobius.com/2013/08/c-string-to-int/ might help for #11897, comparing between various alternatives
160 2017-12-14 13:53:15	0|gribble|https://github.com/bitcoin/bitcoin/issues/11897 | Replace atoi64 with ParseInt64 · Issue #11897 · bitcoin/bitcoin · GitHub
161 2017-12-14 13:54:06	0|Varunram|oh wait, disregard that, my bad
162 2017-12-14 15:55:54	0|BlueMatt|#11884 looks merge-able
163 2017-12-14 15:55:56	0|gribble|https://github.com/bitcoin/bitcoin/issues/11884 | Remove unused include in hash.cpp by kallewoof · Pull Request #11884 · bitcoin/bitcoin · GitHub
164 2017-12-14 16:01:41	0|bitcoin-git|13bitcoin/06master 143f09e03 15Karl-Johan Alm: Remove unused include in hash.cpp
165 2017-12-14 16:01:41	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/2ae58d5bfb76...66479c0e611a
166 2017-12-14 16:01:42	0|bitcoin-git|13bitcoin/06master 1466479c0 15Wladimir J. van der Laan: Merge #11884: Remove unused include in hash.cpp...
167 2017-12-14 16:02:13	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11884: Remove unused include in hash.cpp (06master...0620171213-unneeded-include-hash-cpp) 02https://github.com/bitcoin/bitcoin/pull/11884
168 2017-12-14 16:02:43	0|wumpus|yep
169 2017-12-14 16:33:51	0|BlueMatt|if someone wants to kill uselessly-trivial prs: #10839 could be merged
170 2017-12-14 16:33:53	0|gribble|https://github.com/bitcoin/bitcoin/issues/10839 | Dont use pass by reference to const for cheaply-copied types (bool, char, etc.) by practicalswift · Pull Request #10839 · bitcoin/bitcoin · GitHub
171 2017-12-14 16:39:25	0|cfields|#11842 is trivial and merge-ready too
172 2017-12-14 16:39:27	0|gribble|https://github.com/bitcoin/bitcoin/issues/11842 | [build] Add missing stuff to clean-local by kallewoof · Pull Request #11842 · bitcoin/bitcoin · GitHub
173 2017-12-14 16:43:01	0|bitcoin-git|13bitcoin/06master 14b341143 15Karl-Johan Alm: [build] Add missing stuff to clean-local...
174 2017-12-14 16:43:01	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/66479c0e611a...3c8f0a3b8e67
175 2017-12-14 16:43:02	0|bitcoin-git|13bitcoin/06master 143c8f0a3 15Wladimir J. van der Laan: Merge #11842: [build] Add missing stuff to clean-local...
176 2017-12-14 16:43:32	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11842: [build] Add missing stuff to clean-local (06master...06buildsys-cleanup) 02https://github.com/bitcoin/bitcoin/pull/11842
177 2017-12-14 17:28:34	0|bitcoin-git|13bitcoin/06master 1499ba0c3 15practicalswift: Don't use pass by reference to const for cheaply-copied types (bool, char, etc.).
178 2017-12-14 17:28:34	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/3c8f0a3b8e67...c66adb286a89
179 2017-12-14 17:28:35	0|bitcoin-git|13bitcoin/06master 14c66adb2 15Wladimir J. van der Laan: Merge #10839: Don't use pass by reference to const for cheaply-copied types (bool, char, etc.)...
180 2017-12-14 17:28:54	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10839: Don't use pass by reference to const for cheaply-copied types (bool, char, etc.) (06master...06dont-pass-by-reference-for-cheaply-copied-types) 02https://github.com/bitcoin/bitcoin/pull/10839
181 2017-12-14 17:59:39	0|maaku|the implementation of BIPs 98, 116, 117 could use some review:
182 2017-12-14 17:59:49	0|maaku|https://github.com/maaku/bitcoin/tree/merkle-branch-verify
183 2017-12-14 17:59:56	0|maaku|https://github.com/maaku/bitcoin/tree/tail-call-semantics
184 2017-12-14 18:00:25	0|maaku|(together they implement the features needed for MAST, currently policy-only)
185 2017-12-14 18:00:33	0|wumpus|would be good to bring up in the meeting
186 2017-12-14 18:02:25	0|maaku|I believe kallewoof is going to make a PR when he's done reviewing it himself, but no harm in others taking a peek too
187 2017-12-14 18:02:56	0|Chris_Stewart_5|maaku: What's up with the goto in the tail-call-semantics? Isn't that pretty ill advised?
188 2017-12-14 18:04:15	0|maaku|Chris_Stewart_5: goto is a funny thing. this is actually the one application goto is the best solution for, where the semantics are well-defined and is the easiest way to accomplish what is desired
189 2017-12-14 18:04:49	0|maaku|it's not possible to do tail-call recursion otherwise, and to my knowledge that's basically the reason goto still exists all these iterations of the C++ standard later
190 2017-12-14 18:05:51	0|Chris_Stewart_5|maaku: So I might be getting my 'tail-calls' mixed up, but does this goto keep a stack frames allocated during the recursive step?
191 2017-12-14 18:06:06	0|Chris_Stewart_5|like tail recursion in a functional lang
192 2017-12-14 18:07:34	0|maaku|A new stack frame is not created for the call itself. Any changes to the stack are properly unwound, with destructors called for things that fall out of scope, or stack allocations made and constructors called for things you skip over in other applications of goto (not here)
193 2017-12-14 18:08:49	0|maaku|for example, if the `if {}` statement that had the goto had its own variable that was an instance of the class, the goto would have called the destructor and deallocated it before jumping up to the start of the function
194 2017-12-14 18:09:36	0|maaku|or as an actual example, vfExec is destroyed as part of the goto
195 2017-12-14 18:09:47	0|maaku|(and then recreated when execution reaches it again)
196 2017-12-14 18:12:56	0|maaku|from cppreference:
197 2017-12-14 18:12:58	0|maaku|> If transfer of control exits the scope of any automatic variables (e.g. by jumping backwards to a point before the declarations of such variables or by jumping forward out of a compound statement where the variables are scoped), the destructors are called for all variables whose scope was exited, in the order opposite to the order of their construction.
198 2017-12-14 18:16:04	0|Chris_Stewart_5|maaku: so why can't we just recursively call `EvalScript` inside of VerifyScript?
199 2017-12-14 18:16:22	0|Chris_Stewart_5|and have a counter or whatever of how many recursive calls we have made
200 2017-12-14 18:16:48	0|Chris_Stewart_5|now that I re-read that i'm not sure if that made sense.
201 2017-12-14 18:17:15	0|maaku|(1) that would require refactoring the EvalScript API to carry extra parameters (like the alt stack) as arguments; (2) that would not be safe if/when the limitation of single-recursion is dropped
202 2017-12-14 18:18:11	0|maaku|this is an easier, more targetted change that enables just the functionality required without large code changes, with well defined semantics (even if the use of goto is unusal)
203 2017-12-14 18:18:35	0|sipa|why not wrap the part you're jumping over in a loop?
204 2017-12-14 18:18:54	0|Chris_Stewart_5|^
205 2017-12-14 18:19:03	0|Chris_Stewart_5|or just recursively call EvalScript here? https://github.com/maaku/bitcoin/blob/tail-call-semantics/src/script/interpreter.cpp#L1050
206 2017-12-14 18:19:44	0|Chris_Stewart_5|maybe I am missing some goto functionality here, but it seems like it would be almost identical to just call EvalScritp() instead of using goto
207 2017-12-14 18:20:07	0|sipa|i admit there are use cases for goto, and dismissing it unconditionally is very much a cargo cult thing to do
208 2017-12-14 18:20:16	0|sipa|but i don't think you need it here
209 2017-12-14 18:20:55	0|maaku|Chris_Stewart_5: look at the altstack and nOpCount variables
210 2017-12-14 18:22:18	0|maaku|sipa: a do-while would be equivalent, if slightly more verbose, at the additional review cost of indenting 1000 lines of code
211 2017-12-14 18:22:44	0|maaku|that's up to kallewoof
212 2017-12-14 18:23:15	0|Chris_Stewart_5|maaku: Ah ok I think i see what you are saying. C++ allows for default args right? But I guess that is still pretty unfortunate
213 2017-12-14 18:23:36	0|sipa|review with ?w=1 (in github) or -w (in git) makes indentation changes trivial to review
214 2017-12-14 18:27:32	0|maaku|sipa: I'm sure it would be a stumbling block for many still, unfortunately.
215 2017-12-14 18:28:05	0|sipa|maaku: i expect that a goto would be even more so
216 2017-12-14 18:28:50	0|sipa|the altstack trick is neat; it allows doing this without any new script versioning at all
217 2017-12-14 18:28:51	0|maaku|re: goto I guess it comes down to encoding semantic intent. a do {} while(!done) construct where done is a boolean variable set inside the loop under complex conditions is not a clearer encoding of the semantic intent, which is to restart execution of the function from the beginning
218 2017-12-14 18:29:16	0|maaku|this is why I am handing it over to kallewoof though, who will make the call on making such changes
219 2017-12-14 18:29:21	0|sipa|ok
220 2017-12-14 18:30:34	0|maaku|yes, and I have another simple soft-fork that recovers script versioning inside the witness itself, which would allow us to later remove the altstack trick without needing a new "script version" as presently defined
221 2017-12-14 18:32:43	0|sipa|i'm still very unconfortable with needing code execution before knowing what code is executable, though
222 2017-12-14 18:33:33	0|maaku|?
223 2017-12-14 18:34:34	0|sipa|you don't distinguish code and data
224 2017-12-14 18:35:03	0|sipa|anything can be either, up to the end of the (top level) program
225 2017-12-14 18:35:04	0|maaku|I mean what are your concerns?
226 2017-12-14 18:35:12	0|sipa|static analysis
227 2017-12-14 18:35:32	0|maaku|(as a lisper I have no sympathy for that general concern ;) )
228 2017-12-14 18:35:43	0|sipa|haha
229 2017-12-14 18:35:46	0|maaku|static analysis of what, limits? those are gone in this iteration
230 2017-12-14 18:36:51	0|sipa|can you enumerate all possible code paths ahead of time?
231 2017-12-14 18:42:17	0|maaku|yes
232 2017-12-14 18:43:01	0|maaku|I'm not sure if that's generally provable in the sense that you can show non-decidable scripts aren't possible to write
233 2017-12-14 18:43:43	0|maaku|but the way this is anticipated to be used, and especially with only single recursion, it is straightforward to show all possible code paths
234 2017-12-14 18:43:54	0|sipa|well there are certainly trivial counterexamples, like just "OP_0 OP_TOALTSTACK"
235 2017-12-14 18:44:07	0|sipa|which permits executing anything?
236 2017-12-14 18:45:29	0|maaku|I expect actual deployment to be of the form [root 1 MERKLEBRANCHVERIFY 2DROP 2DROP N*TOALTSTACK] with [argN ... arg1 script proof] as the witness
237 2017-12-14 18:45:44	0|maaku|it's trivial to show all code paths there -- expand the merkle tree
238 2017-12-14 18:45:58	0|sipa|fair enough
239 2017-12-14 18:46:13	0|sipa|i would just be more confortable with having that property guaranteed
240 2017-12-14 18:46:33	0|maaku|(actually [root 2 MERKLEBRANCHVERIFY] for anyone paying close attention)
241 2017-12-14 18:47:07	0|maaku|it's guaranteed in that construct, or related constructs
242 2017-12-14 18:48:29	0|maaku|I guess I'm not understanding why this is a concern -- is there something you are worried about? witness malleability?
243 2017-12-14 18:49:03	0|sipa|i'm not worried, i'm uneasy
244 2017-12-14 18:49:49	0|sipa|just the thought of having code be subject to other code seems so hard to reason about
245 2017-12-14 18:50:27	0|maaku|well keep in mind that tail recursion can only add spend conditions
246 2017-12-14 18:50:53	0|sipa|but counts towards sigops
247 2017-12-14 18:51:41	0|maaku|nope
248 2017-12-14 18:51:48	0|sipa|nope?
249 2017-12-14 18:52:29	0|maaku|tail recursion policy scripts do not add to any aggregate limits, including sigops. see bip 117
250 2017-12-14 18:52:53	0|sipa|ouch
251 2017-12-14 18:53:35	0|maaku|not really. the worst you could possibly do with a 4MB block is 30s of signature verification, which could be dropped to 1-2s with a reasonable fix
252 2017-12-14 18:53:45	0|maaku|so why do we maintain these limits going forward?
253 2017-12-14 18:53:53	0|sipa|that's utterly unacceptable
254 2017-12-14 18:54:38	0|maaku|it's less than other attack vectos we can't do much about, with the fix in place at least, and it costs 1 block's worth of fee income to perform
255 2017-12-14 18:54:45	0|jonasschnelli|sipa: when I'm scanning the UTXO set with the CCoinsViewCursor (while, cursor.Next()) is there a way to calculate the progress? Similar to your https://github.com/bitcoin/bitcoin/blob/master/src/txdb.cpp#L387?
256 2017-12-14 18:55:01	0|maaku|sipa: I suggest actually running the numbers and seeing how much of an issue it is for yourself
257 2017-12-14 18:55:14	0|sipa|maaku: *seconds* of CPU time?
258 2017-12-14 18:55:20	0|sipa|for a block?
259 2017-12-14 18:55:49	0|sipa|what other attack vectors
260 2017-12-14 18:56:06	0|maaku|conservative (high) estimates for a worst-case adversarially constructed block that is nothing but signature verifications
261 2017-12-14 18:56:21	0|maaku|I'm not sure why this is surprising You can fit 64k signatures in a 4MB block
262 2017-12-14 18:57:29	0|maaku|it would take a few seconds to verify 64k signatures
263 2017-12-14 18:57:48	0|sipa|well the concern is that you may construct signatures in less than 70ish byte per check
264 2017-12-14 18:58:04	0|sipa|but i guess your fix is relying on caching to avoid that
265 2017-12-14 18:58:12	0|sipa|which probably works
266 2017-12-14 18:58:30	0|maaku|or the trivial fix I alluded to above -- a per-script sigop limit of size(script+witness)/72
267 2017-12-14 18:58:49	0|sipa|ah, i missed that
268 2017-12-14 18:59:19	0|maaku|I didn't say it, but that's what I was alluding to. Might not be easy to be per-input with sigagg, but could still be a per-tx limit
269 2017-12-14 18:59:40	0|sipa|still, if i'm reading things correctly, it's the outer script's sigop limit that is discarded; the inner sceipt still counts?
270 2017-12-14 19:00:30	0|lightningbot|Meeting started Thu Dec 14 19:00:30 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
271 2017-12-14 19:00:30	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
272 2017-12-14 19:00:30	0|wumpus|#startmeeting
273 2017-12-14 19:00:31	0|maaku|opposite. the sigops are picked up by static analysis of the outer script, which if it only contains a NOP4 (MBV) and stack oeprations is 0
274 2017-12-14 19:00:37	0|jtimon|hi
275 2017-12-14 19:00:54	0|jonasschnelli|hi
276 2017-12-14 19:00:54	0|wumpus|#bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag
277 2017-12-14 19:00:56	0|achow101|hi
278 2017-12-14 19:01:02	0|kanzure|hi.
279 2017-12-14 19:01:06	0|cfields|hi
280 2017-12-14 19:01:19	0|wumpus|#topic high priority for review
281 2017-12-14 19:01:24	0|wumpus|#link https://github.com/bitcoin/bitcoin/projects/8
282 2017-12-14 19:01:25	0|Provoostenator|hi
283 2017-12-14 19:01:37	0|sipa|hi
284 2017-12-14 19:01:41	0|luke-jr|multiwallet gui can be added back in
285 2017-12-14 19:01:56	0|BlueMatt|#11639
286 2017-12-14 19:01:58	0|gribble|https://github.com/bitcoin/bitcoin/issues/11639 | Rewrite the interface between validation and net_processing wrt DoS by TheBlueMatt · Pull Request #11639 · bitcoin/bitcoin · GitHub
287 2017-12-14 19:02:05	0|wumpus|I think we managed to merge two high-priority PRs this week, woohoo
288 2017-12-14 19:02:15	0|sipa|woohoo
289 2017-12-14 19:02:32	0|wumpus|now all we really want is #11403 :)
290 2017-12-14 19:02:39	0|gribble|https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
291 2017-12-14 19:02:40	0|jnewbery|hi
292 2017-12-14 19:02:48	0|jonasschnelli|Added #11383 to the high prio project
293 2017-12-14 19:02:51	0|gribble|https://github.com/bitcoin/bitcoin/issues/11383 | Basic Multiwallet GUI support by luke-jr · Pull Request #11383 · bitcoin/bitcoin · GitHub
294 2017-12-14 19:03:05	0|cfields|should've named it "trivial SegWit wallet support". Those get merged quicker :)
295 2017-12-14 19:03:13	0|jonasschnelli|hah
296 2017-12-14 19:03:15	0|wumpus|segwit wallet before multiwallet please :)
297 2017-12-14 19:03:20	0|promag|hi
298 2017-12-14 19:03:41	0|jonasschnelli|Yes. 11383 needs more reviews first
299 2017-12-14 19:03:59	0|achow101|I'll actually start working on #10367 again after finals this week
300 2017-12-14 19:04:02	0|gribble|https://github.com/bitcoin/bitcoin/issues/10367 | [test] Test abortrescan command. by kallewoof · Pull Request #10367 · bitcoin/bitcoin · GitHub
301 2017-12-14 19:04:10	0|achow101|*#10637
302 2017-12-14 19:04:13	0|gribble|https://github.com/bitcoin/bitcoin/issues/10637 | Coin Selection with Murchs algorithm by achow101 · Pull Request #10637 · bitcoin/bitcoin · GitHub
303 2017-12-14 19:04:34	0|BlueMatt|we're getting really close on #11281 which is also high-prio and I think also #10387
304 2017-12-14 19:04:36	0|BlueMatt|so thats nice
305 2017-12-14 19:04:36	0|wumpus|added BlueMatt #11639
306 2017-12-14 19:04:37	0|gribble|https://github.com/bitcoin/bitcoin/issues/11281 | Avoid permanent cs_main/cs_wallet lock during RescanFromTime by jonasschnelli · Pull Request #11281 · bitcoin/bitcoin · GitHub
307 2017-12-14 19:04:39	0|gribble|https://github.com/bitcoin/bitcoin/issues/10387 | Eventually connect to NODE_NETWORK_LIMITED peers by jonasschnelli · Pull Request #10387 · bitcoin/bitcoin · GitHub
308 2017-12-14 19:04:40	0|gribble|https://github.com/bitcoin/bitcoin/issues/11639 | Rewrite the interface between validation and net_processing wrt DoS by TheBlueMatt · Pull Request #11639 · bitcoin/bitcoin · GitHub
309 2017-12-14 19:05:21	0|wumpus|yep, getting there
310 2017-12-14 19:05:24	0|BlueMatt|ryanofsky: asked for #11687
311 2017-12-14 19:05:27	0|gribble|https://github.com/bitcoin/bitcoin/issues/11687 | External wallet files by ryanofsky · Pull Request #11687 · bitcoin/bitcoin · GitHub
312 2017-12-14 19:06:13	0|wumpus|added
313 2017-12-14 19:06:22	0|wumpus|but let's focus on segwit wallet please
314 2017-12-14 19:06:41	0|BlueMatt|yea, I mean there's also like 3 or 4 bugs on master that need fixing for 0.16...
315 2017-12-14 19:06:54	0|wumpus|all the other things are nice but what people really want at this point is segwit wallet
316 2017-12-14 19:07:28	0|wumpus|I get bothered a lot about it so I'm happy to pass it on :p
317 2017-12-14 19:07:45	0|wumpus|other topics?
318 2017-12-14 19:08:24	0|gribble|https://github.com/bitcoin/bitcoin/issues/11888 | Prevent Opening Wallets Simultaneously in Two Instances · Issue #11888 · bitcoin/bitcoin · GitHub
319 2017-12-14 19:08:25	0|gribble|https://github.com/bitcoin/bitcoin/issues/11822 | Severe memory leak on current master · Issue #11822 · bitcoin/bitcoin · GitHub
320 2017-12-14 19:08:26	0|gribble|https://github.com/bitcoin/bitcoin/issues/11512 | Use GetDesireableServiceFlags in seeds, dnsseeds, fixing static seed adding by TheBlueMatt · Pull Request #11512 · bitcoin/bitcoin · GitHub
321 2017-12-14 19:08:26	0|promag|will sipa include Qt changes in #11403?
322 2017-12-14 19:08:31	0|wumpus|#action merge segwit wallet
323 2017-12-14 19:08:33	0|gribble|https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
324 2017-12-14 19:08:54	0|jnewbery|Quick topic: can I shill for the Coredev tech days in New York, March 5th-7th?
325 2017-12-14 19:09:08	0|wumpus|#topic coredev tech announcement
326 2017-12-14 19:09:09	0|BlueMatt|jnewbery: I think you just did
327 2017-12-14 19:09:15	0|cfields|woohoo!
328 2017-12-14 19:09:50	0|jnewbery|I've sent invites to everyone I think contributes regularly to Bitcoin Core or lightning implementations. If you think you should have got an invite and haven't, plese message me
329 2017-12-14 19:09:52	0|BlueMatt|put it on your calendar! week after fc so book your flights back via ny!
330 2017-12-14 19:09:59	0|jonasschnelli|I think I should merge https://github.com/coredev-tech/coredev-dot-tech/pull/1
331 2017-12-14 19:10:05	0|achow101|is it up on coredev.tech yet?
332 2017-12-14 19:10:13	0|jnewbery|jonasschnelli: yes please!
333 2017-12-14 19:10:13	0|jonasschnelli|jnewbery: have you invited promag?
334 2017-12-14 19:10:33	0|jnewbery|jonasschnelli: yes
335 2017-12-14 19:11:20	0|jnewbery|that's all my shilling :)
336 2017-12-14 19:11:20	0|promag|yes he did
337 2017-12-14 19:11:35	0|luke-jr|proposed topic: status of meeting summaries on the website
338 2017-12-14 19:11:45	0|jonasschnelli|Thanks for organising jnewbery! To bad I can't attend....
339 2017-12-14 19:12:20	0|maaku|jnewbery: New York is a big place. Where is it?
340 2017-12-14 19:12:20	0|wumpus|BlueMatt: seems they were already tagged for 0.16 except #11824
341 2017-12-14 19:12:22	0|gribble|https://github.com/bitcoin/bitcoin/issues/11824 | Block ActivateBestChain to empty validationinterface queue by TheBlueMatt · Pull Request #11824 · bitcoin/bitcoin · GitHub
342 2017-12-14 19:12:32	0|jnewbery|sorry jonas :(
343 2017-12-14 19:12:32	0|sipa|that needs tagging
344 2017-12-14 19:12:35	0|jonasschnelli|jnewbery: keep the location discolued
345 2017-12-14 19:12:38	0|luke-jr|maaku: "We're still working on final confirmation for the location, but it's almost certain to be in Lower Manhattan, close to The Battery."
346 2017-12-14 19:12:40	0|jonasschnelli|*disclosed
347 2017-12-14 19:12:42	0|luke-jr|oops
348 2017-12-14 19:12:43	0|wumpus|better to send the address in private
349 2017-12-14 19:12:53	0|BlueMatt|wumpus: yes, I'm aware, I was pointing out that those three are issues which fix current master bugs ie are blocking 0.16, unlike much of the 0.16 tagged things
350 2017-12-14 19:12:58	0|luke-jr|hopefully that wasn't too much detail
351 2017-12-14 19:12:58	0|maaku|"Lower Manhatten, close to The Battery" was all I was looking for
352 2017-12-14 19:13:17	0|wumpus|BlueMatt: yeah if there's things tagged 0.16 that shouldn't be, let me know
353 2017-12-14 19:13:22	0|wumpus|BlueMatt: I'll bump them to 0.17
354 2017-12-14 19:13:34	0|BlueMatt|"whatever makes it in", right? :p
355 2017-12-14 19:14:04	0|instagibbs|oh meeting, hi
356 2017-12-14 19:14:09	0|wumpus|yes, but if it shouldn't hold up the release it shouldn't really be tagged w/  specific release
357 2017-12-14 19:14:21	0|jtimon|so after #11403 gets merged, what's the timeline for "whatever makes it in" ?
358 2017-12-14 19:14:28	0|gribble|https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
359 2017-12-14 19:14:30	0|luke-jr|wumpus: then why tag anything? :p
360 2017-12-14 19:14:59	0|BlueMatt|wumpus: heh, ok, so lets see, untag 7664, 7729, 7949, 7955, 8501, 9502, 9728....yea, pretty much everything there
361 2017-12-14 19:15:00	0|wumpus|after 11403 makes it in we should go to bugfixing only
362 2017-12-14 19:15:14	0|luke-jr|even Segwit wallet is a "early release trigger", not a blocker ;)
363 2017-12-14 19:15:20	0|jtimon|wumpus: I see
364 2017-12-14 19:15:32	0|BlueMatt|most 0.16-tagged things really dont need a tag
365 2017-12-14 19:15:35	0|sipa|wumpus: i guess that means we shouldn't have tags for future releases
366 2017-12-14 19:15:43	0|sipa|only for backport branches
367 2017-12-14 19:15:55	0|BlueMatt|we should just have a "fixes current master bug" tag which has to be cleared for each release
368 2017-12-14 19:15:55	0|wumpus|sipa: unless they're bugfixes that really need to get in
369 2017-12-14 19:16:06	0|BlueMatt|or i guess stop tagging things that dont fit into that category
370 2017-12-14 19:16:08	0|jonasschnelli|Mabe a tag for "aims for next release"?
371 2017-12-14 19:16:14	0|wumpus|well, github has milestones, not 'current master'
372 2017-12-14 19:16:23	0|BlueMatt|jonasschnelli: doesnt everything aim for next release?
373 2017-12-14 19:16:25	0|wumpus|at least now they will stick which is useful for historical reference
374 2017-12-14 19:16:29	0|BlueMatt|i mean occasionally not, but its rare
375 2017-12-14 19:16:38	0|jonasschnelli|BlueMatt: that is a good questions... or "candidate for next release"?
376 2017-12-14 19:17:03	0|wumpus|the 'future' milestone is for unlikely things that need a lot more work
377 2017-12-14 19:17:19	0|wumpus|so probably not next release
378 2017-12-14 19:18:03	0|gmaxwell|release candidate on tuesday then?
379 2017-12-14 19:18:05	0|jonasschnelli|Usually agile development works with "priorities"..
380 2017-12-14 19:18:05	0|luke-jr|jonasschnelli: everything is a candidate if it gets enough review ;p
381 2017-12-14 19:18:05	0|sipa|wumpus: perhaps a tag "release blocker" rather than a spdcific version milestone is better for those?
382 2017-12-14 19:18:17	0|wumpus|sipa: I prefer a milestone, we have too many tags already
383 2017-12-14 19:18:21	0|sipa|ok
384 2017-12-14 19:18:23	0|wumpus|sipa: at least this is displayed in a different place
385 2017-12-14 19:18:39	0|luke-jr|jonasschnelli: that assumes someone gets to decide priorities for other people
386 2017-12-14 19:18:40	0|sipa|right
387 2017-12-14 19:18:42	0|wumpus|ok, any real topics?
388 2017-12-14 19:18:56	0|jonasschnelli|luke-jr: Yes. Agree. It's kinda impossible
389 2017-12-14 19:19:04	0|wumpus|luke-jr: we have 'high priority' which we already discuss every week
390 2017-12-14 19:19:11	0|wumpus|there's no point in other priorities really
391 2017-12-14 19:19:13	0|luke-jr|[19:11:35] <luke-jr> proposed topic: status of meeting summaries on the website
392 2017-12-14 19:19:25	0|luke-jr|wumpus: sure, just pointing out it has its limits
393 2017-12-14 19:19:28	0|wumpus|#topic meeting summaries
394 2017-12-14 19:19:32	0|gmaxwell|I've been seeing highish connection counts, appears to be organic.  Non-listening nodes appear to have grown a lot in the last three months.
395 2017-12-14 19:19:52	0|achow101|luke-jr: what about the meeting summaries
396 2017-12-14 19:19:58	0|gmaxwell|Who called this meeting?
397 2017-12-14 19:20:40	0|sipa|?
398 2017-12-14 19:20:45	0|luke-jr|I don't actually know what's up with meeting summaries, but the last one was 2 months ago (with a huge gap before that), and people are wondering
399 2017-12-14 19:20:55	0|achow101|TheSadFace is the person I got to write them
400 2017-12-14 19:21:04	0|achow101|he's been doing them slowly
401 2017-12-14 19:21:07	0|BlueMatt|https://github.com/bitcoin-core/bitcoincore.org/pulls
402 2017-12-14 19:21:14	0|BlueMatt|I mean there are ones sitting there ready to merge
403 2017-12-14 19:21:19	0|BlueMatt|so...that sounds like a first step
404 2017-12-14 19:21:38	0|TheSadFace|Hello everyone, yeah sorry about how slow it's going... After finals I plan to catch up to the present time
405 2017-12-14 19:21:44	0|achow101|the last few weeks have been slightly busy because of exams, so meeting notes haven't really gotten written. but hopefully a bunch will be written in the next few weeks
406 2017-12-14 19:21:45	0|wumpus|oh right I'm allowed to merge things on the bitcoincore.org site now
407 2017-12-14 19:21:49	0|wumpus|:D
408 2017-12-14 19:22:01	0|BlueMatt|lol after you broke the site!
409 2017-12-14 19:22:10	0|luke-jr|ok, so basically it's taken care of, just a matter of time
410 2017-12-14 19:22:14	0|achow101|luke-jr: yes
411 2017-12-14 19:22:31	0|TheSadFace|luke-jr: Yeah just had a crazy last bit of the semester
412 2017-12-14 19:22:32	0|wumpus|well the site was still working :)
413 2017-12-14 19:22:36	0|Provoostenator|I think just posting the chat log quickly after the meeting is better than nothing.
414 2017-12-14 19:22:48	0|sipa|TheSadFace: very happy that someone's doing that
415 2017-12-14 19:22:50	0|wumpus|Provoostenator: the bot uploads the chat log
416 2017-12-14 19:22:53	0|sipa|even if it takes a while
417 2017-12-14 19:23:14	0|wumpus|e.g. http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-12-07-19.00.log.html for last meeting
418 2017-12-14 19:23:16	0|Provoostenator|But those don't show up here: https://bitcoincore.org/en/meetings/
419 2017-12-14 19:23:26	0|TheSadFace|sipa: Thanks!
420 2017-12-14 19:23:34	0|Provoostenator|For the RSS folks out there...
421 2017-12-14 19:23:42	0|wumpus|TheSadFace: yes, thanks a lot
422 2017-12-14 19:23:55	0|luke-jr|Provoostenator: wouldn't that make RSS more complex? if it shows up with the log, but then the summary added later.,.
423 2017-12-14 19:23:56	0|achow101|Provoostenator: "To view more recent logs, all meeting logs and raw minutes can be found here."
424 2017-12-14 19:24:00	0|bitcoin-git|[13bitcoin] 15instagibbs opened pull request #11900: [policy] simplify CheckMinimalPush checks, add safety assert (06master...06checkminimal) 02https://github.com/bitcoin/bitcoin/pull/11900
425 2017-12-14 19:24:03	0|achow101|here links to http://www.erisian.com.au/meetbot/bitcoin-core-dev/
426 2017-12-14 19:24:05	0|Provoostenator|It might be better to just always generate a post on /meetings, edit the post later.
427 2017-12-14 19:24:27	0|luke-jr|I don't personally use RSS, but I would imagine it would be better if the post only showed when the summary is done
428 2017-12-14 19:24:41	0|luke-jr|otherwise people will try to read, see no summary, and forget to go back later
429 2017-12-14 19:25:00	0|Provoostenator|True, maybe have a second RSS feed with just the logs?
430 2017-12-14 19:25:07	0|Provoostenator|For people who want them fast.
431 2017-12-14 19:25:20	0|achow101|also, who owns the meetbot and the site where all of the meeting logs and stuff go?
432 2017-12-14 19:25:26	0|wumpus|aj does
433 2017-12-14 19:25:29	0|luke-jr|why not they just connect to the webchat? :P
434 2017-12-14 19:25:41	0|MarcoFalke|Provoostenator: Scroll back on botbot?
435 2017-12-14 19:26:38	0|cfields|very quick topic suggestion: toolchain builder progress
436 2017-12-14 19:26:50	0|wumpus|#topic toolchain builder progress
437 2017-12-14 19:26:51	0|luke-jr|actually, maybe we should link the webchat on the page?
438 2017-12-14 19:27:04	0|wumpus|is a read-only link to the webchat possible?
439 2017-12-14 19:27:06	0|cfields|i'm knee-deep in compiler builds. slowly taking shape. that is all :)
440 2017-12-14 19:27:09	0|BlueMatt|pr in time for 0.16 to replace gitian for 0.16, right?
441 2017-12-14 19:27:10	0|wumpus|if not, please don't do it
442 2017-12-14 19:27:22	0|cfields|heh
443 2017-12-14 19:27:25	0|achow101|wumpus: could link to botbot which is read only
444 2017-12-14 19:27:30	0|wumpus|achow101: +1
445 2017-12-14 19:27:44	0|luke-jr|wait, replacing gitian? :/
446 2017-12-14 19:28:17	0|cfields|first step will just be a toolchain that we use in gitian rather than whatever ubuntu ships
447 2017-12-14 19:28:40	0|cfields|that will mean that we can very easily use whatever compilers/versions we want for gitian/travis
448 2017-12-14 19:28:45	0|wumpus|that would help in cases like we have with ubuntu 16.04, where the mingw64 compiler is completely broken
449 2017-12-14 19:28:57	0|cfields|right
450 2017-12-14 19:29:09	0|sipa|wow, even in travis?
451 2017-12-14 19:29:19	0|Chris_Stewart_5|cfields: nice!
452 2017-12-14 19:29:42	0|cfields|after that, I'd like to discuss something more long-term. But replacing Gitian would still be a long way away
453 2017-12-14 19:29:53	0|luke-jr|within gitian sgtm, although hopefully only as-needed for Travis since it's already slow
454 2017-12-14 19:29:56	0|BlueMatt|#link http://vxer.org/lib/pdf/Reflections%20on%20Trusting%20Trust.pdf
455 2017-12-14 19:30:17	0|gmaxwell|luke-jr: the would it be slow in travis? it would get cached.
456 2017-12-14 19:30:34	0|cfields|luke-jr: the idea would be to host our toolchains somewhere, so that travis just pulls them like anything else
457 2017-12-14 19:30:40	0|cfields|right
458 2017-12-14 19:30:57	0|BlueMatt|will this make bitcoin core the first open source project to do releases using the 1984-suggested toolchain system? =D
459 2017-12-14 19:31:18	0|sipa|BlueMatt: we don't ship with our own CPU microcode yet :(
460 2017-12-14 19:31:23	0|cfields|gmaxwell: also, the clang/gcc thing is kinda moot. We'll want to build them with each-other anyway, so going clang-only wouldn't make things any easier
461 2017-12-14 19:31:28	0|wumpus|1984 toolchain system doesn't have a good ring to it
462 2017-12-14 19:31:29	0|luke-jr|sipa: yet.
463 2017-12-14 19:31:30	0|BlueMatt|sipa: lol, ok, fair
464 2017-12-14 19:31:46	0|BlueMatt|wumpus: all the better to spy on you with
465 2017-12-14 19:31:53	0|wumpus|BlueMatt: :D
466 2017-12-14 19:32:40	0|achow101|is the goal to eventually get rid of gitian?
467 2017-12-14 19:32:44	0|gmaxwell|BlueMatt: IIRC diverse double compilation was not suggested by KT.
468 2017-12-14 19:32:53	0|cfields|BlueMatt: heh yes. The initial toolchain will likely take ages and ages to build. But after it's done once, updates are quick and easy
469 2017-12-14 19:33:02	0|luke-jr|achow101: I would hope not. Gitian is handy.
470 2017-12-14 19:33:04	0|wumpus|good to hear you're making progress cfields
471 2017-12-14 19:33:07	0|BlueMatt|gmaxwell: oh? how did I get that confused...who suggested it?
472 2017-12-14 19:33:24	0|luke-jr|achow101: at least not unless there's an alternative that isn't Bitcoin/Core-specific
473 2017-12-14 19:33:29	0|achow101|luke-jr: same, although it does need a bit of fixing I think
474 2017-12-14 19:33:36	0|gmaxwell|KT made the problem statement, I don't think DDC was suggested until david wheeler's thesis in the mid-oughts.
475 2017-12-14 19:33:43	0|BlueMatt|ah, ok
476 2017-12-14 19:34:07	0|wumpus|I think abstractly gitian as a launcher for deterministic containers that build is a good concept
477 2017-12-14 19:34:25	0|luke-jr|(and also not distro-specific ;)
478 2017-12-14 19:35:14	0|jtimon|what would be the advantageof getting rid of gitian?
479 2017-12-14 19:35:16	0|wumpus|it does have too much overhead (runnig a full ubuntu VM inside, which upgrades everyt ime), and is pretty hard to initially set up
480 2017-12-14 19:35:53	0|cfields|wumpus: agreed that the concept is good. It's just got lots of rough edges
481 2017-12-14 19:36:00	0|wumpus|the advantage is not in getting rid in it, but building something better
482 2017-12-14 19:36:08	0|luke-jr|wumpus: even making the updates persistent might be an improvement there
483 2017-12-14 19:36:11	0|achow101|I think that setting up a new gitian environment has been slowly getting harder
484 2017-12-14 19:36:29	0|cfields|luke-jr: with the toolchain stuff done, we won't need to do the updates anymore
485 2017-12-14 19:36:40	0|cfields|it'll be distro-agnostic
486 2017-12-14 19:36:48	0|wumpus|cfields: what about the windows installer stuff
487 2017-12-14 19:37:04	0|luke-jr|building NSIS should be trivial I'd think
488 2017-12-14 19:37:06	0|wumpus|cfields: I mean NSIS - we should probably build that too, then
489 2017-12-14 19:37:12	0|wumpus|oh no building NSIS is not trivial :(
490 2017-12-14 19:37:13	0|luke-jr|Gentoo has an ebuild, so just port that
491 2017-12-14 19:37:29	0|cfields|wumpus: right, i haven't gotten that far yet. But I suspect we'll just need to suck it up and build it
492 2017-12-14 19:37:34	0|wumpus|the problem is that it's a mix of cross compield windows code and native code, and has a sucky build system
493 2017-12-14 19:38:14	0|wumpus|yes
494 2017-12-14 19:38:18	0|luke-jr|correction: Gentoo *used* to have an ebuild :x
495 2017-12-14 19:38:19	0|cfields|have no alternatives cropped up in the last ~10 years?
496 2017-12-14 19:38:27	0|wumpus|using the one in 12.04 isn't acceptable anymore at least
497 2017-12-14 19:38:34	0|wumpus|eh, 14.04
498 2017-12-14 19:38:53	0|luke-jr|I have a copy of the last ebuild in my overlay, it's only 111 lines
499 2017-12-14 19:39:18	0|cfields|luke-jr: that assumes you already have scons built and working
500 2017-12-14 19:39:22	0|wumpus|windows has a native installer db system that would be preferable to use
501 2017-12-14 19:39:33	0|wumpus|but porting the installer over to that would be... work
502 2017-12-14 19:39:40	0|luke-jr|yes :p
503 2017-12-14 19:40:44	0|cfields|well we can always take the toolchain stuff but still rely on a few bits and pieces from ubuntu until we get it all worked out
504 2017-12-14 19:40:50	0|wumpus|sure
505 2017-12-14 19:41:05	0|luke-jr|doesn't the toolchain stuff depend on a native autotools/make anyway?
506 2017-12-14 19:41:10	0|luke-jr|what harm in using native scons?
507 2017-12-14 19:41:20	0|wumpus|ah yes window's own system is msi
508 2017-12-14 19:41:31	0|cfields|luke-jr: depends how deep we want to go
509 2017-12-14 19:41:51	0|wumpus|thinking of it, might not be that easy to make those in cross-build
510 2017-12-14 19:41:55	0|maaku|wumpus: building a gitian vm can be easily scriptable. I had vagrant scripts for doing this since 2013, but weren't upstreamed out of lack of interest
511 2017-12-14 19:42:20	0|wumpus|maaku: there is a script for that now
512 2017-12-14 19:42:21	0|maaku|maintaining a script to construct a gitian vm solves the accessibilty problem (and gets more people using gitian)
513 2017-12-14 19:42:40	0|cfields|wumpus: msi's? IIRC gnu ld can target them, at least
514 2017-12-14 19:43:03	0|sipa|i also have brief libsecp256k1 update
515 2017-12-14 19:43:08	0|wumpus|contrib/gitian-build.sh
516 2017-12-14 19:43:22	0|achow101|maaku: unfortunately sometimes gitian doesn't get setup even with a script
517 2017-12-14 19:43:22	0|wumpus|cfields: ok, so if we can get someone to make a msi installer for us, we could use that instead
518 2017-12-14 19:43:34	0|achow101|it might fail at some random point in the process for some unknown reason
519 2017-12-14 19:43:39	0|cfields|wumpus: sure, something to look into
520 2017-12-14 19:43:43	0|wumpus|the problem is that it has a lot to accomodate, because setting up the kvm/lxc is slightly different on differnt systems
521 2017-12-14 19:44:04	0|wumpus|anyhow we'll figure it out, time for next topic
522 2017-12-14 19:44:05	0|wumpus|#topic libsecp256k1 update (sipa)
523 2017-12-14 19:44:11	0|luke-jr|doesn't KVM just work on all modern systems?
524 2017-12-14 19:44:25	0|wumpus|luke-jr: not inside VMs
525 2017-12-14 19:44:28	0|cfields|luke-jr: nested is a pain
526 2017-12-14 19:44:29	0|sipa|in the past week we've finally merged multi-multiplication support in libsecp256k1: https://github.com/bitcoin-core/secp256k1/pull/486
527 2017-12-14 19:44:38	0|maaku|wumpus: which is why you outsource the vm maintenance to an existing cross-platform vm management tool, like vagrant, and then do lxc-gitian within that vm
528 2017-12-14 19:44:56	0|jonasschnelli|sipa; what are the benefits?
529 2017-12-14 19:45:04	0|achow101|sipa: that's the pippenger thing?
530 2017-12-14 19:45:05	0|sipa|this is the low-level functionality for efficiently computing a*A + b*B + c*C + ..., with a,b,c scalars and A,B,C points
531 2017-12-14 19:45:20	0|sipa|it is not exposed currently (except for tests and benchmarks)
532 2017-12-14 19:45:22	0|cfields|ah, nice :)
533 2017-12-14 19:45:35	0|sipa|but it's the basis for efficiently building signature aggregation, batch validation, bulletproofs, ...
534 2017-12-14 19:45:47	0|jonasschnelli|nice
535 2017-12-14 19:46:15	0|wumpus|maaku: ok, maybe discuss with cfields
536 2017-12-14 19:46:37	0|wumpus|sipa: congrats!
537 2017-12-14 19:46:50	0|sipa|it doesn't currently affect anything in bitcoin, but i thought about mentioning it here as it's under the bitcoin-core repo and all that
538 2017-12-14 19:47:21	0|cfields|sipa: how do you picture that working with threading?
539 2017-12-14 19:47:36	0|cfields|batches of batches?
540 2017-12-14 19:47:50	0|sipa|cfields: split up the problem in N parts, run each part on one thread, and add the results together
541 2017-12-14 19:47:59	0|cfields|(I realize that's still a ways out)
542 2017-12-14 19:48:03	0|cfields|roger
543 2017-12-14 19:48:20	0|sipa|there are algorithms to actually be more efficient than that, but they need high communication across threads
544 2017-12-14 19:48:24	0|sipa|which may or may not be worth it
545 2017-12-14 19:48:35	0|sipa|(and be much harder to do API-wise)
546 2017-12-14 19:48:57	0|wumpus|one step at a time
547 2017-12-14 19:49:04	0|sipa|anyway, thanks to andytoshi and nickler, and peterdettman who all contributed optimizations
548 2017-12-14 19:49:46	0|michagogo|Sorry I'm late. IIRC a while back I made a gitian-building appliance with video instructions for recreating it from scratch
549 2017-12-14 19:49:47	0|cfields|nice work
550 2017-12-14 19:50:00	0|sipa|and of course gmaxwell for all imput and discussions :)
551 2017-12-14 19:50:05	0|sipa|*input
552 2017-12-14 19:50:28	0|achow101|sipa: so what do we need to be able to use this in Bitcoin?
553 2017-12-14 19:50:49	0|sipa|achow101: ECDSA can't really take advantage of it in its current form
554 2017-12-14 19:50:51	0|michagogo|(Wow, apparently that was over a year ago: https://1drv.ms/f/s!AvCguGMVwWzLgxJPeXdvaQVJ2WJq )
555 2017-12-14 19:50:52	0|cfields|a use-case
556 2017-12-14 19:51:17	0|BlueMatt|ok, any last-minute topics/
557 2017-12-14 19:51:18	0|BlueMatt|?
558 2017-12-14 19:51:33	0|gmaxwell|well I tried to talk about connection slot saturation earlier.
559 2017-12-14 19:51:34	0|sipa|achow101: slightly modified ECDSA would permit batch validation, but there's no reason to choose that over some form of Schnorr-based signatures
560 2017-12-14 19:51:37	0|maaku|achow101: bitcoin doesn't do multi-generator arithmetic
561 2017-12-14 19:51:57	0|maaku|but it's useful for CT/CA
562 2017-12-14 19:52:17	0|achow101|oh, ok. cool.
563 2017-12-14 19:52:20	0|BlueMatt|gmaxwell: was there much to discuss? thanks for the notice, encourage people to run nodes/increase -maxconnections if possible?
564 2017-12-14 19:52:37	0|sipa|</endtopic>
565 2017-12-14 19:52:38	0|gmaxwell|We need to start looking into reenabling some kind of port forwarding I think.
566 2017-12-14 19:52:43	0|wumpus|so does anyone really get a lot of connections?
567 2017-12-14 19:52:51	0|gmaxwell|the number of non-listning nodes as increased by 50% in the last six months.
568 2017-12-14 19:53:04	0|wumpus|I have maxconnections at 500 on one node and have never got more than 100
569 2017-12-14 19:53:15	0|achow101|wumpus: I have 120 right now
570 2017-12-14 19:53:17	0|sipa|i'm at 124 connections
571 2017-12-14 19:53:18	0|gmaxwell|wumpus: when I was commenting a day ago I had confirmations of >110 on 6 nodes.
572 2017-12-14 19:53:20	0|Provoostenator|Are we sure UDNP works?
573 2017-12-14 19:53:20	0|wumpus|on the other node I'm happy to get more than 10
574 2017-12-14 19:53:32	0|achow101|Provoostenator: it's currently disabled by default
575 2017-12-14 19:53:45	0|sipa|Provoostenator: UPNP?
576 2017-12-14 19:53:47	0|gmaxwell|you'll see less if you're in a /16 with many other nodes in it.
577 2017-12-14 19:53:51	0|jonasschnelli|does NODE_NETWORK_LIMITED helps in this case?
578 2017-12-14 19:53:58	0|sipa|jonasschnelli: perhaps!
579 2017-12-14 19:54:05	0|wumpus|well the netherlands has lots of nodes so I've heard :-)
580 2017-12-14 19:54:08	0|gmaxwell|probably not much.
581 2017-12-14 19:54:14	0|Provoostenator|sipa: that one
582 2017-12-14 19:54:20	0|wumpus|they're not *all* mine :p
583 2017-12-14 19:54:56	0|gmaxwell|Running short on inbounds is the reasonable and expected outcome from not having automatic port forwarding... it's obviously not critical currently, but I think it's becoming more important.
584 2017-12-14 19:55:12	0|achow101|gmaxwell: do you think it would be safe to re-enable UPnP?
585 2017-12-14 19:55:14	0|Provoostenator|Maybe BitcoinQT can encourage users to use UPnP with a little nag?
586 2017-12-14 19:55:22	0|achow101|IIRC it was disabled because of vulnerabilities
587 2017-12-14 19:55:27	0|luke-jr|Provoostenator: better to just make it default then..
588 2017-12-14 19:55:28	0|wumpus|any plans for bitcoin over udp? much easier to port fw there
589 2017-12-14 19:55:31	0|gmaxwell|achow101: bleh. I dunno. that codebase sucks.
590 2017-12-14 19:55:49	0|wumpus|yes, UPNP is not going to be enabled by default again as long as I have a say, I have no confidence in that codebase
591 2017-12-14 19:55:53	0|gmaxwell|achow101: but there are other portforwarding protocols that we could support that are simple.
592 2017-12-14 19:56:05	0|BlueMatt|I believe wumpus has investigated it the most, sadly :(
593 2017-12-14 19:56:07	0|luke-jr|wumpus: what if someone ports it to another UPnP lib? (are there any good ones?)
594 2017-12-14 19:56:43	0|Provoostenator|Without UPnP, we could at least show some instructions that they need to perform the port forwarding ritual.
595 2017-12-14 19:56:50	0|wumpus|wasn't there a better replacement for upnp gmaxwell?
596 2017-12-14 19:57:07	0|luke-jr|other protocols won't help with routers being UPnP..
597 2017-12-14 19:57:11	0|gmaxwell|Yes, there are several.
598 2017-12-14 19:57:12	0|wumpus|something that didn't rely on variable buffers and xml parsing
599 2017-12-14 19:57:28	0|jonasschnelli|Provoostenator: a "connectable" green/read flag and some instruction is probably simple
600 2017-12-14 19:57:33	0|gmaxwell|not as widely supported as UPNP but e.g. all apple networking appliances support the one whos name I can't remember.
601 2017-12-14 19:57:43	0|cfields|Bonjour?
602 2017-12-14 19:57:45	0|gmaxwell|where the protocol is just a trivial struct sent over usp.
603 2017-12-14 19:57:54	0|jonasschnelli|Bonjour is mDNS (that is different)
604 2017-12-14 19:57:57	0|sipa|DLNA?
605 2017-12-14 19:58:22	0|gmaxwell|I'm thinking of NAT-PMP
606 2017-12-14 19:58:24	0|Provoostenator|As well as a P2P message like "please try to connect to me", so it's easier to see if the port is open?
607 2017-12-14 19:58:27	0|luke-jr|does anyone actually use Apple networking appliances? :/
608 2017-12-14 19:58:29	0|sipa|ah yes, that
609 2017-12-14 19:58:53	0|wumpus|NAT-PMP is quite common these days, not only in apple
610 2017-12-14 19:58:56	0|gmaxwell|luke-jr: yes, though I'm sure they're not the most popular... NAT-PMP has support beyond apple of course.
611 2017-12-14 19:59:05	0|Provoostenator|The current instruction says "go to 21 and enter your IP there"
612 2017-12-14 19:59:12	0|gmaxwell|I just mentioned apple as a concrete example that it is widely supported.
613 2017-12-14 19:59:13	0|luke-jr|would be nice to find a quality library that can do both
614 2017-12-14 19:59:18	0|sipa|Provoostenator: ?
615 2017-12-14 19:59:23	0|gmaxwell|Provoostenator: wtf? what "the current instructions" say that?
616 2017-12-14 19:59:49	0|gmaxwell|luke-jr: there is not really a reason for a library for nat-pmp. You send a dozen byte packet over UDP.
617 2017-12-14 19:59:51	0|wumpus|I'd be ok with NAT-PMP on by default
618 2017-12-14 20:00:01	0|gmaxwell|And if you want to know your IP you listen for a similarly structured dozen by UDP reply.
619 2017-12-14 20:00:09	0|achow101|gmaxwell: I think Provoostenator is talking about https://bitcoin.org/en/full-node#port-forwarding
620 2017-12-14 20:00:23	0|wumpus|but no C/C++ xml parser crap again please
621 2017-12-14 20:00:34	0|wumpus|we've pretty much dodged a bullet last time
622 2017-12-14 20:00:37	0|BlueMatt|achow101: oh ffs, can we get that fixed?
623 2017-12-14 20:00:41	0|Provoostenator|(trying to find where I saw that)
624 2017-12-14 20:00:45	0|BlueMatt|<dong>
625 2017-12-14 20:00:49	0|wumpus|#endmeeting
626 2017-12-14 20:00:50	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-12-14-19.00.log.html
627 2017-12-14 20:00:50	0|lightningbot|Meeting ended Thu Dec 14 20:00:49 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
628 2017-12-14 20:00:50	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-12-14-19.00.html
629 2017-12-14 20:00:50	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-12-14-19.00.txt
630 2017-12-14 20:00:52	0|gmaxwell|So in any case, we should look into it more. I don't think we need something as widespread (and poorly implemented) as UPNP.
631 2017-12-14 20:00:55	0|luke-jr|gmaxwell: that explains why I didn't see any libs :P
632 2017-12-14 20:00:57	0|luke-jr|maaku: VM maintenance is exactly what gitian is handy for.. vagrant on the other hand has a ton of deps, one of which is non-free :/
633 2017-12-14 20:01:18	0|gmaxwell|I think NAT-PMP would probably help a lot and wouldn't be a risk.
634 2017-12-14 20:01:18	0|jonasschnelli|sipa: when I'm scanning the UTXO set with the CCoinsViewCursor (while, cursor.Next()) is there a way to calculate the progress? Similar to your https://github.com/bitcoin/bitcoin/blob/master/src/txdb.cpp#L387?
635 2017-12-14 20:01:32	0|sipa|jonasschnelli: you can assume the txids and uniformly distributed
636 2017-12-14 20:01:36	0|wumpus|not sure if I ever made it public, but I could own every bitcoin node starting up in a LAN
637 2017-12-14 20:01:37	0|achow101|Provoostenator: this: https://bitcoin.org/en/full-node#testing-connections
638 2017-12-14 20:01:42	0|achow101|I think that's what you were looking for
639 2017-12-14 20:01:51	0|cfields|wumpus: yikes!
640 2017-12-14 20:01:54	0|sipa|maaku: multi-multiplication is useful even for cryptographic systems that don't use multiple generators
641 2017-12-14 20:01:56	0|Provoostenator|achow101 yes
642 2017-12-14 20:02:10	0|Provoostenator|So now they just need some browser fingerprinting et voila.
643 2017-12-14 20:02:22	0|sipa|maaku: e.g. Schnorr batch validation
644 2017-12-14 20:02:28	0|Provoostenator|Next time you go to a shop, they'll offer you a bitcoin payment option. Super convenient!
645 2017-12-14 20:02:31	0|jonasschnelli|sipa: thanks...
646 2017-12-14 20:02:38	0|jonasschnelli|wumpus: oh.. due to UPnP?
647 2017-12-14 20:02:40	0|achow101|wumpus: how so?
648 2017-12-14 20:02:50	0|wumpus|cfields: was a combination of a heartbleed-like leak (to get the ASLR addresses) and the known vulnerability, both are patched now in any case
649 2017-12-14 20:02:51	0|gmaxwell|sipa: in fact it would be perfectly useful in bitcoin for batch validation if but for the ecda reduction of R.x mod P and the lack of R's sign.
650 2017-12-14 20:03:20	0|sipa|jonasschnelli: so take the top 64 bits of the txid, and convert it to a double... that should increase at a constant rate
651 2017-12-14 20:03:35	0|maaku|luke-jr: there are alternatives to vagrant, but I think you missed the point. use a vagrant-like tool to make a linux vm (centos, ubuntu, I don't care). on THAT system make the gitian VM using the usual scripts
652 2017-12-14 20:03:54	0|gmaxwell|do not just cast the bits to a double, as that could constract signaling nans and other baddness.
653 2017-12-14 20:04:04	0|wumpus|achow101: there was a buffer overflow bug in the miniupnp library at some point, don't have the CVE at hand
654 2017-12-14 20:04:25	0|sipa|gmaxwell: it also wouldn't work
655 2017-12-14 20:04:28	0|gmaxwell|There was more than one.  We'd previously noted that the code smelled.
656 2017-12-14 20:04:29	0|jonasschnelli|sipa: int percentageDone = (int)(high * 100.0 / 65536.0 + 0.5) (can you explain why 65536.0 + 0.5?)
657 2017-12-14 20:04:53	0|cfields|maaku: that's pretty much Gitian's utility though. I'd argue that if you need a vm builder to run the vm builder, one of them needs some love :)
658 2017-12-14 20:04:57	0|sipa|jonasschnelli: i assume that's just looking at the top 16 bits?
659 2017-12-14 20:05:06	0|sipa|jonasschnelli: 16 bits have 65536 possibilities
660 2017-12-14 20:05:07	0|luke-jr|Gentoo let the CVE sit until just a few weeks ago. My workaround was to depend on the fixed version explicitly. :/
661 2017-12-14 20:05:10	0|sipa|0.5 is for rounding
662 2017-12-14 20:05:14	0|jonasschnelli|sipa: okay. I see
663 2017-12-14 20:05:15	0|luke-jr|anyhow, bbl
664 2017-12-14 20:05:48	0|maaku|cfields: how is that gitian's utility? I'm not sure why it should be our business to maintain the gitian setup procedure on every development environment out there
665 2017-12-14 20:06:19	0|wumpus|the vuln was: TALOS-2015-0035 (CVE-2015-6031)
666 2017-12-14 20:06:38	0|wumpus|had to badger ubuntu day in day out to put up an updated libupnpc library
667 2017-12-14 20:06:56	0|sipa|badger badger badger
668 2017-12-14 20:07:14	0|wumpus|bitcoin wasn't the only affected program, but one of the worst, because it had the upnp structures on the stack
669 2017-12-14 20:08:27	0|achow101|what if we just removed UPnP entirely? It's not like people actually seem to be using it.
670 2017-12-14 20:08:48	0|cfields|maaku: right, Gitian's tasked with abstracting that away. But in reality it only behaves on Linux environments that look as it expects. If something like vagrant/docker/etc. does it better, it may make sense to outsource some of it.
671 2017-12-14 20:08:48	0|wumpus|sure, but please implement an alternative first
672 2017-12-14 20:09:05	0|wumpus|NAT-PMP is great but someone has to do it :)
673 2017-12-14 20:09:17	0|gmaxwell|achow101: I think we need at least some kind of internal traversal, perhaps NAT-PMP is enough.
674 2017-12-14 20:12:31	0|wumpus|I'll create an issue for it
675 2017-12-14 20:13:34	0|maaku|cfields: gitian is not designed to work on windows or mac os x or bsd or even non-mainstream linux environments. it expects a standard linux environment. so give it one: use gitian-lxc inside of a vm or container made with more traditional cross-platform support
676 2017-12-14 20:13:52	0|maaku|i'm not saying replace any aspect of gitian. these are totally different problems, and gitian only tackles one of them
677 2017-12-14 20:14:36	0|cfields|maaku: it is intended to work on osx
678 2017-12-14 20:15:23	0|sipa|looking at RFC 6886, NAT-PNP looks absolutely trivial
679 2017-12-14 20:17:03	0|gmaxwell|I think if we didn't care about learning our external IP (we do) it would be a dozen lines of code to support.
680 2017-12-14 20:17:28	0|sipa|oh, you need to know your gateway address
681 2017-12-14 20:17:36	0|sipa|that looks slightly nontrivial, especially across platforms
682 2017-12-14 20:17:40	0|aj|supa: http://miniupnp.free.fr/nat-pmp.html laims it's superceded by rfc6887 "port control protocol"
683 2017-12-14 20:17:45	0|aj|sipa even
684 2017-12-14 20:17:55	0|gmaxwell|aj: yes, though PCP is fully backwards compatible with PMP I believe.
685 2017-12-14 20:18:03	0|cfields|maaku: its primary task is to kick off a vm, run a script, and gather the results. imo the creation of that vm is out of its scope.
686 2017-12-14 20:18:16	0|gmaxwell|and just supports additional features we don't really need (well, IPv6 is among them I think)
687 2017-12-14 20:18:29	0|maaku|cfields: i seem to be failing at comunication with you. i give up, sorry.
688 2017-12-14 20:18:48	0|cfields|sipa: multicast to 0.0.0.0 :p
689 2017-12-14 20:19:43	0|Provoostenator|gmaxwell what do you mean by "care about learning our external ip"?
690 2017-12-14 20:20:13	0|sipa|Provoostenator: NAT-PMP has a way to know what your external IP is
691 2017-12-14 20:20:18	0|sipa|we need that for announcements in addr messages
692 2017-12-14 20:20:30	0|gmaxwell|Provoostenator: we use UPNP for two things: to open the port, and to learn our IP so we can announce it.
693 2017-12-14 20:20:48	0|gmaxwell|there are workarounds we have for the latter, but they're kinda lame, it's much better to learn it from the router.
694 2017-12-14 20:21:10	0|Provoostenator|I see. One (lame) workaround could be to ask another peer I assume?
695 2017-12-14 20:21:28	0|gmaxwell|we do that but the result isn't something we can trust.
696 2017-12-14 20:21:54	0|sipa|very early versions of bitcoin used whatismyip.com, no joke :)
697 2017-12-14 20:22:04	0|sipa|or some site like that
698 2017-12-14 20:22:47	0|Provoostenator|Can't you verify this untrusted IP by pinging it?
699 2017-12-14 20:22:54	0|cfields|maaku: sorry for steamrolling. I'd like to understand the role you see for something like Vagrant.
700 2017-12-14 20:23:21	0|wumpus|#11902
701 2017-12-14 20:23:22	0|gribble|https://github.com/bitcoin/bitcoin/issues/11902 | NAT-PMP port forwarding support · Issue #11902 · bitcoin/bitcoin · GitHub
702 2017-12-14 20:23:44	0|sipa|Provoostenator: so a peer would tell you, "hey, your IP is 192.168.1.1!" and you'd try to ping it, and indeed, it works!
703 2017-12-14 20:23:59	0|Provoostenator|You can't send a payload along with that ping?
704 2017-12-14 20:24:06	0|sipa|Provoostenator: you miss my point
705 2017-12-14 20:24:10	0|gmaxwell|Provoostenator: actually usually from inside nat you can't reach the external IP.
706 2017-12-14 20:24:36	0|Provoostenator|sipa: oh wait, I think I see your point
707 2017-12-14 20:24:38	0|gmaxwell|but what you're thinking of doesn't work either because the peer can mitm anything you do.
708 2017-12-14 20:24:53	0|Provoostenator|Exactly
709 2017-12-14 20:25:18	0|gmaxwell|besides, supporting the discovery part of PMP isn't that much harder.
710 2017-12-14 20:25:50	0|Provoostenator|Sure, just trying to understand why. But that makes sense.
711 2017-12-14 20:26:20	0|Provoostenator|IPv6 is still scheduled for 2008, right?
712 2017-12-14 20:27:00	0|maaku|cfields: setup a standard linux environment in which gitian is run
713 2017-12-14 20:27:02	0|BlueMatt|Provoostenator: yep, we're all preparing to deploy on schedule!
714 2017-12-14 20:27:07	0|sipa|Provoostenator: i had an IPv6 address in 2005 ;)
715 2017-12-14 20:27:18	0|maaku|on any platform, with ~no maintenence burden to bitcoin core
716 2017-12-14 20:28:00	0|maaku|cfields: like this did, although I'd change the approach if I re-did it in 2017 : https://github.com/bitcoin/bitcoin/pull/1597
717 2017-12-14 20:28:08	0|wumpus|lol yes I also had an IPv6 address in the past, but no longer, seems IPv6 support by the big providers in the Netherlands has been postponed indefinitely, they announce and postpone every time
718 2017-12-14 20:29:08	0|wumpus|one provider acquired another provider, cancelling their ongoing ipv6 rollout
719 2017-12-14 20:29:21	0|gmaxwell|lol
720 2017-12-14 20:29:41	0|BlueMatt|lol, monopolistic practices to prevent ipv6 rollout?
721 2017-12-14 20:29:52	0|sipa|apparently my home desktop, behind a NAT, has a global IPv6 address that works :o
722 2017-12-14 20:30:02	0|BlueMatt|my home internet does as well
723 2017-12-14 20:30:04	0|gmaxwell|SURPRISE.
724 2017-12-14 20:30:33	0|gmaxwell|just when you thought you didn't have to worry much about security on random hosts in your home...
725 2017-12-14 20:30:44	0|sipa|it's firewalled of course
726 2017-12-14 20:30:50	0|BlueMatt|InternetOfShitTakesRevenge
727 2017-12-14 20:31:01	0|BlueMatt|heh, my default garbage isnt
728 2017-12-14 20:31:06	0|cfields|maaku: I see
729 2017-12-14 20:32:29	0|sipa|gmaxwell: my machine is reachable in other ways too - i'm just surpised that ISP, router, OS, ... all support IPv6 without any configuration
730 2017-12-14 20:33:02	0|wumpus|yes, hardware and software support for ipv6 support is very good these days
731 2017-12-14 20:33:12	0|wumpus|that's no longer the bottleneck
732 2017-12-14 20:33:20	0|Provoostenator|Wumpus: seems Ziggo is experimenting with IPv6 again though.
733 2017-12-14 20:33:51	0|Provoostenator|Top hit on Google is people trying to downgrade to IPv4 because [something bad].
734 2017-12-14 20:38:52	0|wumpus|Provoostenator: you mean, to IPv6 only?
735 2017-12-14 20:39:18	0|Provoostenator|Yes, I'll just email them to see if that's possible. Then I'll find out how it works and what breaks.
736 2017-12-14 20:39:44	0|wumpus|I'd not be happy with that either, would just like the choice to use IPv6 as well
737 2017-12-14 20:41:28	0|BlueMatt|wumpus: I mean, hey, from a network-management perspective I do get why one might want to drag their feet on ipv6 rollout...the possibility that your users end up joining a DDoS attack because you host garbage IoT devices all over the place that get pop'ed via IPv6 is....much too high. ofc its something they need to deal with *either way*, but...ehh
738 2017-12-14 20:43:48	0|wumpus|BlueMatt: yes, having all devices reachable for incoming connections from outside by default is one of the things I like less about IPv6, although that's not the fault of the protocol but of router's default firewall configuration
739 2017-12-14 20:43:59	0|BlueMatt|indeed
740 2017-12-14 20:44:23	0|Provoostenator|Can't a standard cable modem just block all ports by default?
741 2017-12-14 20:44:41	0|BlueMatt|should, probably, but wont in my experience
742 2017-12-14 20:44:52	0|Provoostenator|So the user just needs to open them, but not forward. Although that's probably still too much of a barrier.
743 2017-12-14 20:44:56	0|wumpus|blocking incoming TCP SYN packets to the entire range would be a start
744 2017-12-14 20:45:18	0|wumpus|but I don't think any routers do that by default
745 2017-12-14 20:45:24	0|gmaxwell|internet of terror
746 2017-12-14 20:47:18	0|wumpus|then again, that would defeat its entire purpose for things like bitcoin and P2P programs, again requiring the users to manually change a setting
747 2017-12-14 20:47:53	0|BlueMatt|gmaxwell: internet of shit!
748 2017-12-14 20:48:12	0|BlueMatt|wumpus: yea, but upnp and auto-forwarding is easy to get right and implement!
749 2017-12-14 20:50:42	0|wumpus|BlueMatt: not quite, though well at least for ipv4 there are protocols for that, I'm not sure what a ipv6 'please allow this port' request would look like
750 2017-12-14 20:51:20	0|BlueMatt|wumpus: I was joking......
751 2017-12-14 20:51:23	0|sipa|wumpus: PCP supports IPv6 IIRC
752 2017-12-14 20:51:29	0|wumpus|in principle it would be the application requesting global scope for a port instead of LAN scope, of course, it's dangerous to allow applications to make those decisions in general
753 2017-12-14 20:54:06	0|sipa|well UPnP/NAT-PMP aren't designed to bypass firewalls, they're to inform the router of port mappings
754 2017-12-14 20:54:16	0|sipa|in IPv6 those should just not be needed anymore
755 2017-12-14 20:54:54	0|wumpus|yeah, 'should'
756 2017-12-14 20:55:05	0|sipa|unfortunately, many people treat the lack of a mapping as a substitute for a firewall, where of course those protocols effectively become a way for application to bypass security
757 2017-12-14 20:55:24	0|wumpus|right
758 2017-12-14 20:56:38	0|wumpus|another problem is that applications and operating systems open all kinds of ports, expecting them to be only open to a LAN instead of to the whole world, whereas most users don't really configure a firewall
759 2017-12-14 20:57:24	0|xames|not possible to use port 80 like skype...
760 2017-12-14 20:57:33	0|wumpus|NAT made developers and users lazy in that way
761 2017-12-14 20:57:50	0|xames|like teamviewer
762 2017-12-14 21:06:10	0|bitcoin-git|[13bitcoin] 15jonasschnelli opened pull request #11903: [trivial] Add required package dependencies for depends cross compilation (06master...062017/12/depends_pkg) 02https://github.com/bitcoin/bitcoin/pull/11903
763 2017-12-14 21:31:25	0|meshcollider|Ah I missed the meeting oops
764 2017-12-14 21:35:45	0|BlueMatt|meshcollider: tsk tsk, no more getting your prs reviewed this week, then :p
765 2017-12-14 21:37:31	0|meshcollider|BlueMatt: how is that different from every other week though ;)
766 2017-12-14 21:37:58	0|BlueMatt|meshcollider: heh, try the high priority review queue, it at least usually gets you one or two reviews in a week :p
767 2017-12-14 22:04:16	0|MarcoFalke|re: jonasschnelli: [OT] what is the fastest way to amend commit the current changes into a non HEAD commit?
768 2017-12-14 22:04:17	0|MarcoFalke|git commit --fixup=${that_non_head_commit} && git rebase --interactive --autosquash ${that_non_head_commit}~
769 2017-12-14 22:07:03	0|wumpus|huh autosquash is nice, so it will automatically mark commits whose message start with squash! as squash and same with fixup!, didn't know about that one
770 2017-12-14 22:07:32	0|BlueMatt|heh, cool
771 2017-12-14 22:08:08	0|meshcollider|You can also turn on autosquash by default with  git config --global rebase.autosquash true
772 2017-12-14 22:08:21	0|meshcollider|so you don't have to use --autosquash every time
773 2017-12-14 22:10:18	0|BlueMatt|I really want a fixup! "Title of Commit to Squash Into"
774 2017-12-14 22:10:33	0|meshcollider|that is what it does?
775 2017-12-14 22:11:17	0|BlueMatt|oh, heh, nice
776 2017-12-14 22:11:27	0|meshcollider|;)
777 2017-12-14 22:15:04	0|MarcoFalke|promag: re ParseInt64
778 2017-12-14 22:15:18	0|MarcoFalke|Imo it should be done at init and then throw an error
779 2017-12-14 22:16:30	0|meshcollider|MarcoFalke: I'm going to work on some stronger argument checking as soon as I can
780 2017-12-14 22:16:35	0|MarcoFalke|When your node is running for a day and you sendtoaddress, it is too late to crash on "Wrong tx fee set on command line"
781 2017-12-14 22:16:42	0|MarcoFalke|meshcollider: Cool
782 2017-12-14 22:16:46	0|wumpus|that's what I also said, we should have some options mechanism that parses all options at init time,
783 2017-12-14 22:17:00	0|MarcoFalke|wumpus: Jup, like python :)
784 2017-12-14 22:17:01	0|wumpus|it's crazy to parse options every time in a loop anyway
785 2017-12-14 22:17:48	0|wumpus|or every time a RPC command is called
786 2017-12-14 22:18:21	0|MarcoFalke|It is still good to have the GetArg in place, but internally they might use some sort of caching
787 2017-12-14 22:18:35	0|wumpus|just call the getarg in init
788 2017-12-14 22:18:36	0|meshcollider|GetArg just looks up in mapArgs
789 2017-12-14 22:18:42	0|wumpus|then assign to a global
790 2017-12-14 22:18:47	0|wumpus|or have some automatic system to do that
791 2017-12-14 22:19:03	0|wumpus|caching is also unnecessary, it can just be a variable
792 2017-12-14 22:19:14	0|wumpus|no need for any lookup at all
793 2017-12-14 22:19:15	0|meshcollider|wumpus all args are parsed in ArgsManager::ParseParameters
794 2017-12-14 22:19:27	0|MarcoFalke|wumpus: You'd have to sprikle the code with locks in case we allow args to change at run time, no?
795 2017-12-14 22:19:33	0|wumpus|we don't allow that
796 2017-12-14 22:19:42	0|MarcoFalke|There is a pull to do that, though
797 2017-12-14 22:19:48	0|meshcollider|which one?
798 2017-12-14 22:19:52	0|wumpus|well yes in that case you'd have to protect the values with a lock
799 2017-12-14 22:20:03	0|wumpus|it's tsill better than parsing every time
800 2017-12-14 22:20:19	0|MarcoFalke|wumpus: My style preferense would be to put the lock in the GetArg
801 2017-12-14 22:20:20	0|wumpus|but most settings don't really make sense to change at run time
802 2017-12-14 22:20:26	0|MarcoFalke|The getarg can return the variable
803 2017-12-14 22:20:34	0|wumpus|using strings to refer to variables just doesn't make sense when you know what you're accessing
804 2017-12-14 22:20:41	0|MarcoFalke|jup
805 2017-12-14 22:20:49	0|wumpus|there's this whole hash lookup every time that makes no sense
806 2017-12-14 22:20:53	0|jnewbery|wumpus: Perhaps #11415 is ready for merge?
807 2017-12-14 22:20:56	0|gribble|https://github.com/bitcoin/bitcoin/issues/11415 | [RPC] Disallow using addresses in createmultisig by achow101 · Pull Request #11415 · bitcoin/bitcoin · GitHub
808 2017-12-14 22:22:17	0|wumpus|jnewbery: thanks
809 2017-12-14 22:22:29	0|meshcollider|wumpus: so you suggest adding a private variable inside ArgsManager for each argument?
810 2017-12-14 22:22:37	0|meshcollider|I can probably work on this today
811 2017-12-14 22:23:00	0|wumpus|meshcollider: I'm not sure that's a good idea, because that makes argmanager have to know about all options in the entire program
812 2017-12-14 22:23:16	0|wumpus|meshcollider: ideally there would be some way to register arguments with the argument manager
813 2017-12-14 22:23:22	0|wumpus|meshcollider: same as we do with RPC methods
814 2017-12-14 22:23:37	0|meshcollider|wumpus: ah yes that's a cool idea
815 2017-12-14 22:23:47	0|wumpus|meshcollider: this information could include the name, documentaion, type, as well as a pointer to the variable to update
816 2017-12-14 22:24:07	0|MarcoFalke|and valid ranges for integers, e.g.
817 2017-12-14 22:24:09	0|wumpus|meshcollider: well it's pretty much what quake already did in 1995 or so :)
818 2017-12-14 22:24:11	0|wumpus|yep
819 2017-12-14 22:24:13	0|meshcollider|MarcoFalke: do you know what PR is the one which allows changing them at runtime? I'd like to take a quick look at it
820 2017-12-14 22:24:31	0|MarcoFalke|it could be one of luke's
821 2017-12-14 22:24:35	0|aj|meshcollider: having a table of argument name -> reference to global that gets populated with value by parseargs+config?
822 2017-12-14 22:24:37	0|MarcoFalke|might be closed
823 2017-12-14 22:25:16	0|wumpus|MarcoFalke: yep a range or if that's not enough, a functor that does checking
824 2017-12-14 22:25:25	0|meshcollider|do we want to add a whole lot more global variables though
825 2017-12-14 22:25:43	0|wumpus|you could put them in a structure per module
826 2017-12-14 22:25:44	0|aj|wumpus, meshcollider, *: happy with the overall approach of #11862 at this point, btw?
827 2017-12-14 22:25:46	0|gribble|https://github.com/bitcoin/bitcoin/issues/11862 | [concept] Network specific conf sections by ajtowns · Pull Request #11862 · bitcoin/bitcoin · GitHub
828 2017-12-14 22:26:14	0|YellowSphere|Hi there.
829 2017-12-14 22:26:27	0|wumpus|e.g. a module could register its own globals, so they're only global static in that compilation unit
830 2017-12-14 22:26:32	0|wumpus|same as the RPC registration
831 2017-12-14 22:27:02	0|wumpus|aj: ACK on the conept, haven't reviewed the code
832 2017-12-14 22:27:07	0|meshcollider|aj: so far yep it looks sensible
833 2017-12-14 22:27:08	0|MarcoFalke|meshcollider: Maybe this one https://github.com/bitcoin/bitcoin/pull/7510/files ?
834 2017-12-14 22:27:47	0|aj|wumpus: cool, i'll review the code, add some tests and maybe even docs then
835 2017-12-14 22:28:10	0|aj|wumpus: modules registering their own options/globals would fit well with declaring some options as needing to be specified per network
836 2017-12-14 22:28:26	0|wumpus|aj: yes, that could be one of the registration parameters
837 2017-12-14 22:28:59	0|aj|wumpus: maybe help text could be one of the params too?
838 2017-12-14 22:29:12	0|wumpus|aj: absolutely, yes
839 2017-12-14 22:29:19	0|meshcollider|aj: he already mentioned that ;)
840 2017-12-14 22:29:28	0|MarcoFalke|falls under "documentation"
841 2017-12-14 22:29:43	0|meshcollider|Ok I'll get started then
842 2017-12-14 22:30:18	0|meshcollider|aj's PR should be merged first but I won't base mine on top of it until its been more thoroughly reviewed / less likely to drastically change
843 2017-12-14 22:30:27	0|wumpus|meshcollider: the idea would be that everything about the option is specified at registration, so that it's in one place and that's the module where it gets used
844 2017-12-14 22:30:58	0|danklasson|I don't know if you guys know. But supposedly this guy set up this fund where you can apply for 1 million dollars donation. Would you guys say that could be used to hire a bunch of devs working on several projects related to Bitcoin, such as segwit supported wallets and LN. What's your thoughts regarding this? https://pineapplefund.org/
845 2017-12-14 22:32:51	0|meshcollider|danklasson: I don't think bitcoin core counts as a charity ;)
846 2017-12-14 22:34:11	0|danklasson|meshcollider: I know but I'm guessing they would be willing to make an exception
847 2017-12-14 22:34:23	0|wumpus|yeah, I've had the question before 'how can I pay to help lightning development', I had no idea
848 2017-12-14 22:36:18	0|danklasson|wumpus: I read that few people are working on LN. If we had a bunch of money we could hire a bunch of devs to work on it. I bet I can get a bunch of guys on board to get the ball rolling
849 2017-12-14 22:36:39	0|wumpus|in open source it's individual developers working on things, there's no one dealing out work items, and allocating resources
850 2017-12-14 22:36:52	0|ryanofsky|imo, gflags has a good model for registering options. lets you declare options where used, creates variables to avoid lookups, and combines with documentation: https://gflags.github.io/gflags/#define
851 2017-12-14 22:37:18	0|danklasson|wumpus: not necessarily. a lot of companies contribute to open source too
852 2017-12-14 22:37:23	0|wumpus|sure you could ask individual developers for donation address
853 2017-12-14 22:38:04	0|danklasson|i was thinking something more like setting up a foundation that hires people and allocates them to different projects
854 2017-12-14 22:38:47	0|wumpus|heh that didn't go too well with the bitcoin foundation... anyhow off topic here
855 2017-12-14 22:39:19	0|danklasson|is there a better channel to discuss this?
856 2017-12-14 22:39:25	0|wumpus|#bitcoin
857 2017-12-14 22:39:42	0|Deacyde|/join #bitcoin
858 2017-12-14 22:39:48	0|Deacyde|:) \
859 2017-12-14 22:40:51	0|danklasson|ok, thanks
860 2017-12-14 22:41:10	0|wumpus|ryanofsky: agree, looks decent
861 2017-12-14 22:59:51	0|phantomcircuit|i've got a node in blocks only mode with a peer that claims to be 0.15.1 sending transactions in violation of the protocol
862 2017-12-14 23:00:25	0|phantomcircuit|lol i also have a peer claiming to be 0.15.0.1
863 2017-12-14 23:02:12	0|BlueMatt|yea, thats been a common complaint, dont know that anyone has reproduced it with their own nodes, but people seem to pop up claiming that every now and again
864 2017-12-14 23:02:37	0|BlueMatt|I'm betting its random garbage nodes hacked to relay lots of shit, cause several people have gone looking for a bug there and failed to find one, afair
865 2017-12-14 23:03:00	0|BlueMatt|err...not *common*, but it gets mentioned once or twice every now and again
866 2017-12-14 23:03:06	0|BlueMatt|we should probably just ban peers for that
867 2017-12-14 23:03:43	0|phantomcircuit|possibly nodes that have whitelisted 0.0.0.0/0
868 2017-12-14 23:26:06	0|bitcoin-git|[13bitcoin] 15MeshCollider opened pull request #11904: Add a lock to the wallet directory (06master...06201712_walletdir_lock) 02https://github.com/bitcoin/bitcoin/pull/11904
869 2017-12-14 23:26:10	0|meshcollider|BlueMatt: ^
870 2017-12-14 23:26:41	0|meshcollider|wumpus: that needs a 0.16 milestone