1 2017-06-29 01:18:36	0|phantomcircuit|gmaxwell, btw master compiles for me
  2 2017-06-29 01:31:06	0|phantomcircuit|why did the pull testing stuff get changed?
  3 2017-06-29 01:31:12	0|phantomcircuit|oh travis changed
  4 2017-06-29 06:40:37	0|bitcoin-git|[13bitcoin] 15jonasschnelli closed pull request #9722: GUI: Display warning when attempting address reuse (06master...06reuse) 02https://github.com/bitcoin/bitcoin/pull/9722
  5 2017-06-29 09:05:36	0|bitcoin-git|13bitcoin/06master 143c85332 15Wladimir J. van der Laan: contrib: Update laanwj key...
  6 2017-06-29 09:05:36	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/90a002ea647d...080ec5209172
  7 2017-06-29 09:05:37	0|bitcoin-git|13bitcoin/06master 14080ec52 15MarcoFalke: Merge #10688: contrib: Update laanwj key...
  8 2017-06-29 09:06:07	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #10688: contrib: Update laanwj key (06master...062017_06_laanwj_key) 02https://github.com/bitcoin/bitcoin/pull/10688
  9 2017-06-29 09:56:09	0|wumpus|cfields: btw any idea what to do here? https://github.com/bitcoin/bitcoin/issues/10670   arguably the openbsd case is worst-case, they use an ancient GNU binutils
 10 2017-06-29 09:57:40	0|wumpus|would be possible to detect this in configure, I guess, and then not disable the sse-reliant stuff
 11 2017-06-29 09:57:48	0|wumpus|s/disable/enable
 12 2017-06-29 11:09:04	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #10701: Remove the virtual specifier for functions with the override specifier (06master...06virtual-override) 02https://github.com/bitcoin/bitcoin/pull/10701
 13 2017-06-29 12:26:08	0|bitcoin-git|[13bitcoin] 15MeshCollider opened pull request #10702: [Trivial] Improve end-of-namespace comment consistency (06master...06improve-end-of-namespace-comment-consistence) 02https://github.com/bitcoin/bitcoin/pull/10702
 14 2017-06-29 12:33:15	0|wumpus|what is people's obsession with en-of-namespace comments
 15 2017-06-29 12:33:52	0|wumpus|we've just merged one three days ago (#9544), and now we need another PR?
 16 2017-06-29 12:33:54	0|gribble|https://github.com/bitcoin/bitcoin/issues/9544 | [trivial] Add end of namespace comments. Improve consistency. by practicalswift · Pull Request #9544 · bitcoin/bitcoin · GitHub
 17 2017-06-29 13:04:03	0|bitcoin-git|13bitcoin/06master 14fd9599b 15practicalswift: [qt] Avoid potential null pointer dereference in TransactionView::exportClicked()
 18 2017-06-29 13:04:03	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/080ec5209172...4c72cc33ebcc
 19 2017-06-29 13:04:04	0|bitcoin-git|13bitcoin/06master 144c72cc3 15Wladimir J. van der Laan: Merge #10673: [qt] Avoid potential null pointer dereference in TransactionView::exportClicked()...
 20 2017-06-29 13:04:32	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10673: [qt] Avoid potential null pointer dereference in TransactionView::exportClicked() (06master...06null-pointer-dereference) 02https://github.com/bitcoin/bitcoin/pull/10673
 21 2017-06-29 13:36:07	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #10703: [tests] Allow tests to pass when stderr is non-empty (06master...06test_stderr) 02https://github.com/bitcoin/bitcoin/pull/10703
 22 2017-06-29 13:57:50	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #10704: [tests] nits in dbcrash.py (06master...06dbcrashtestnits) 02https://github.com/bitcoin/bitcoin/pull/10704
 23 2017-06-29 15:20:02	0|jonasschnelli|Should we crate a "trivial" label?
 24 2017-06-29 15:20:39	0|jonasschnelli|or something that point concludes "typo only fixes / comments / etc."?
 25 2017-06-29 15:25:13	0|wumpus|we had a trivial label in the past, I removed that at some point because it didn't add anything that 'docs/output' or 'refactoring' doesn't do
 26 2017-06-29 15:25:46	0|wumpus|it made people have the idea that labeling something 'trivial' would make it accepted sooner, prompting the creating of tons of trivial changes
 27 2017-06-29 15:26:18	0|wumpus|in any case, better to label specifically. 'trivial' doesn't really tell anything about the change
 28 2017-06-29 15:27:19	0|wumpus|e.g. a comment change would be a documentation change
 29 2017-06-29 15:39:30	0|wumpus|dbcrash.py travis troubles https://github.com/bitcoin/bitcoin/pull/10704#issuecomment-312005841
 30 2017-06-29 15:40:59	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 7 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/4c72cc33ebcc...65cc7aacfbfc
 31 2017-06-29 15:41:00	0|bitcoin-git|13bitcoin/06master 1437065d2 15John Newbery: [tests] remove unused imports from utils.py
 32 2017-06-29 15:41:00	0|bitcoin-git|13bitcoin/06master 14f1fe536 15John Newbery: [tests] fix flake8 warnings in test_framework.py and util.py
 33 2017-06-29 15:41:01	0|bitcoin-git|13bitcoin/06master 14cad967a 15John Newbery: [tests] Move stop_node and start_node methods to BitcoinTestFramework...
 34 2017-06-29 15:41:24	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #10556: Move stop/start functions from utils.py into BitcoinTestFramework (06master...06testframeworkstopstart) 02https://github.com/bitcoin/bitcoin/pull/10556
 35 2017-06-29 15:49:19	0|jonasschnelli|wumpus: I see, good point about the "trivial" label.
 36 2017-06-29 15:59:01	0|sdaftuar|wumpus: thanks for the heads up, i'll investigate the dbcrash issue
 37 2017-06-29 16:00:22	0|wumpus|sdaftuar: they look like different problems; 248398016 seems a race issue (sending command to terminated process), 248398018 is a timeout while running `generate`. It's a tad strange that both problems happen to be in dbcrash.
 38 2017-06-29 16:00:57	0|sdaftuar|wumpus: it looks like the issue in 248398016 may just be that i got the exception name wrong somehow
 39 2017-06-29 16:01:08	0|sdaftuar|https://travis-ci.org/bitcoin/bitcoin/jobs/248398016#L3321
 40 2017-06-29 16:03:51	0|sdaftuar|we can bump the rpctimeout for the test to fix that second problem
 41 2017-06-29 16:05:00	0|wumpus|sdaftuar: oops, good catch, didn't notice that between all the errors
 42 2017-06-29 16:06:48	0|wumpus|yes that seems just a case of 'travis VM too slow for timeout'
 43 2017-06-29 16:36:25	0|cfields|wumpus: hmm
 44 2017-06-29 16:37:00	0|cfields|wumpus: re the openbsd assembler, i think we could patch it to use the hex, same as rdrand? :(
 45 2017-06-29 16:38:22	0|cfields|(i don't know enough about assemblers, but i figured that was done that way for exactly this reason)
 46 2017-06-29 16:38:54	0|cfields|but yes, we could also check during configure
 47 2017-06-29 16:48:59	0|sipa|cfields: yeah, i tried using rdrand as a mnemonic, but the osx assembler didn't accept it on travis
 48 2017-06-29 16:49:26	0|sipa|hex always works, but the downside is that you must hardcode the registers
 49 2017-06-29 16:50:34	0|wumpus|cfields: I don't particularly care if the sse-accelerated code is not used on openbsd
 50 2017-06-29 16:50:44	0|wumpus|cfields: they have to use openssl -no-asm as well
 51 2017-06-29 16:51:16	0|cfields|heh, really? That's a big hit
 52 2017-06-29 16:51:31	0|wumpus|we definitely shouldn't dumb down the code just for this case, there's a large chance that openbsd will switch to clang at some pointa different as
 53 2017-06-29 16:51:34	0|wumpus|yes, really
 54 2017-06-29 16:52:21	0|cfields|yikes, ok
 55 2017-06-29 16:52:57	0|wumpus|I don't want to get involved in the politics here, they choose to use an old as that doens't support modern instructions, they get slower code. It does need to compile, though.
 56 2017-06-29 16:53:43	0|cfields|ok. let's just add an inline-compile check rather than trying to hunt down the assembler though. some (clang, at least) let you choose between an internal assembler or external
 57 2017-06-29 16:53:54	0|sipa|using hex asm also has the advantage of not needing separately compiled objects just to have access to one asm instruction
 58 2017-06-29 16:53:58	0|wumpus|their gcc is also -  by choice - an ancient version
 59 2017-06-29 16:54:18	0|wumpus|ok, just don't do this for openbsd, it's likely a temporary issue
 60 2017-06-29 16:54:25	0|sipa|agree
 61 2017-06-29 17:49:30	0|bitcoin-git|[13bitcoin] 15ka7 opened pull request #10705: Trivial: spelling fixes (06master...06feature/spelling) 02https://github.com/bitcoin/bitcoin/pull/10705
 62 2017-06-29 17:56:27	0|bitcoin-git|[13bitcoin] 15laanwj pushed 7 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/65cc7aacfbfc...0c3542e5dec3
 63 2017-06-29 17:56:28	0|bitcoin-git|13bitcoin/06master 1400cb69b 15Jonas Schnelli: [Qt] allow to execute a callback during splashscreen progress
 64 2017-06-29 17:56:28	0|bitcoin-git|13bitcoin/06master 14ae09d45 15Jonas Schnelli: Allow to shut down during txdb upgrade
 65 2017-06-29 17:56:29	0|bitcoin-git|13bitcoin/06master 14316fcb5 15Jonas Schnelli: Allow to cancel the txdb upgrade via splashscreen callback
 66 2017-06-29 17:57:02	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10660: Allow to cancel the txdb upgrade via splashscreen keypress 'q' (06master...062017/06/chainstate_update_prog) 02https://github.com/bitcoin/bitcoin/pull/10660
 67 2017-06-29 18:18:38	0|bitcoin-git|[13bitcoin] 15morcos opened pull request #10706: Improve wallet fee logic and fix GUI bugs (06master...06improveWalletFeeLogic) 02https://github.com/bitcoin/bitcoin/pull/10706
 68 2017-06-29 18:20:06	0|bitcoin-git|[13bitcoin] 15laanwj pushed 8 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/0c3542e5dec3...2935b469ae96
 69 2017-06-29 18:20:07	0|bitcoin-git|13bitcoin/06master 146d22b2b 15Matt Corallo: Pull script verify flags calculation out of ConnectBlock
 70 2017-06-29 18:20:07	0|bitcoin-git|13bitcoin/06master 14b5fea8d 15Matt Corallo: Cache full script execution results in addition to signatures...
 71 2017-06-29 18:20:08	0|bitcoin-git|13bitcoin/06master 14eada04e 15Matt Corallo: Do not print soft-fork-script warning with -promiscuousmempool
 72 2017-06-29 18:20:20	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10192: Cache full script execution results in addition to signatures (06master...062017-04-cache-scriptchecks) 02https://github.com/bitcoin/bitcoin/pull/10192
 73 2017-06-29 18:24:34	0|sipa|w00t
 74 2017-06-29 18:24:48	0|BlueMatt|hey, neat
 75 2017-06-29 18:24:53	0|BlueMatt|0.15 is coming together :)
 76 2017-06-29 18:25:28	0|Dizzle|Definitely. I'm sad unix sockets aren't in. Looking forward to that for my electrum server.
 77 2017-06-29 18:29:01	0|wumpus|Dizzle: good to hear at least someone was waiting for the UNIX sockets stuff, did you review/test the PR?
 78 2017-06-29 18:29:34	0|Dizzle|wumpus: I will be this weekend, am getting an electrumx patch ready for it.
 79 2017-06-29 18:29:48	0|wumpus|awesome
 80 2017-06-29 18:33:21	0|wumpus|Dizzle: are you going to use P2P or RPC over unix sockets?
 81 2017-06-29 18:33:30	0|Dizzle|RPC
 82 2017-06-29 18:33:30	0|wumpus|(or both)
 83 2017-06-29 18:35:21	0|Dizzle|Electrum servers tend to maintain their own utxo DB. Syncing with your node's db over RPC is a bit of a bottleneck. Using asynchronous i/o speeds things along but there is plenty of overhead using the TCP loopback when both softwares are in the same operating environment.
 84 2017-06-29 18:37:05	0|bitcoin-git|[13bitcoin] 15morcos opened pull request #10707: Better API for estimatesmartfee RPC  (06master...06bettersmartfeeapi) 02https://github.com/bitcoin/bitcoin/pull/10707
 85 2017-06-29 18:37:13	0|wumpus|oh interesting, I had mostly seen the UNIX sockets as security improvement, not so much for performance, but yes avoiding local TCP might save some overhead
 86 2017-06-29 18:48:43	0|gmaxwell|wumpus: well for p2p it would be a performance improvement if we changed the protocol and dropped the 'crc', but I don't think we were planning on doing that.
 87 2017-06-29 18:49:27	0|jcorgan|i have a non-bitcoin related application that communicates between two processes using a unix socket at a continuous 5Gbps data rate
 88 2017-06-29 18:49:44	0|jcorgan|uses zmq over unix socket
 89 2017-06-29 18:50:11	0|gmaxwell|jcorgan: yea, right now though for us the fact that every p2p message gets sha2ed is way more overhead than TCP.
 90 2017-06-29 18:50:31	0|wumpus|http://bhavin.directi.com/unix-domain-sockets-vs-tcp-sockets/
 91 2017-06-29 18:50:38	0|jcorgan|oh, sure, i was just commenting that unix sockets are pretty fast
 92 2017-06-29 18:51:01	0|wumpus|so there's really a performance gain in both latency and throughput because no local network needs to be emulates, I never realized that
 93 2017-06-29 18:51:17	0|wumpus|makes sense though
 94 2017-06-29 18:51:34	0|gmaxwell|perhaps an input to the BIP151 stuff... that it should be possible to run it in a mode that turns off the auth for use over a domain socket at least.
 95 2017-06-29 18:52:16	0|wumpus|well one of the uses for UNIX would be for tor; in that case we certainly don't want to disable the crcing, or auth. But agree it'd be nice to have it as possibility.
 96 2017-06-29 18:52:57	0|gmaxwell|yea. and one always needs to worry about downgrade attacks.
 97 2017-06-29 18:53:03	0|jonasschnelli|gmaxwell: great idea
 98 2017-06-29 18:53:30	0|wumpus|it'd be another kind of whitebind 'nocrcbind' 'noauthbind'
 99 2017-06-29 18:53:38	0|jonasschnelli|gmaxwell: But then there would be no checksum... if you disable the poly1305 mac?
100 2017-06-29 18:53:40	0|wumpus|bindflags extension
101 2017-06-29 18:53:58	0|gmaxwell|jonasschnelli: right but there isn't any need for one with a purely local unix domain socket.
102 2017-06-29 18:54:08	0|wumpus|jonasschnelli: over a local socket, when communicating with local software, there's no point
103 2017-06-29 18:54:20	0|jonasschnelli|Indeed.
104 2017-06-29 18:54:30	0|jonasschnelli|Corruption through socket coms is not possible I guess?
105 2017-06-29 18:54:39	0|wumpus|and the permissions of the socket itself are used for authentication
106 2017-06-29 18:54:41	0|jonasschnelli|*domain sockets
107 2017-06-29 18:54:50	0|gmaxwell|jonasschnelli: no, not any more than any random memory anywhere.
108 2017-06-29 18:54:54	0|wumpus|no, unless memory/cpu corruption, in which case there's other issues
109 2017-06-29 18:55:24	0|wumpus|this is a SOCK_STREAM AF_UNIX socket, so neither reordering nor corruption nor packet loss should happen
110 2017-06-29 18:55:29	0|jonasschnelli|I see... yes. That mode would be awesome... especially for wallets (stuff I'm writing into libbtc) that downloads everything from the local peer
111 2017-06-29 18:56:16	0|wumpus|it's theoretically possible for SOCK_DGRAM AF_UNIX sockets to deliver packets out of order, though I've never heard of an OS that does that (but anyhow not an issue for us)
112 2017-06-29 18:57:21	0|jcorgan|one nice thing about ZMQ is that with a parameter change I can do the same thing between network endpoints on different hosts or two processes on the same host over a unix socket
113 2017-06-29 18:57:25	0|jcorgan|no code changes
114 2017-06-29 18:57:47	0|jcorgan|(or even two threads using zmq over shared memory)
115 2017-06-29 18:57:59	0|wumpus|yes, that's nice
116 2017-06-29 18:58:29	0|jcorgan|anyway, carry on
117 2017-06-29 19:00:03	0|gmaxwell|#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
118 2017-06-29 19:00:12	0|wumpus|#startmeeting
119 2017-06-29 19:00:13	0|lightningbot|Meeting started Thu Jun 29 19:00:12 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
120 2017-06-29 19:00:13	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
121 2017-06-29 19:00:42	0|sipa|oi
122 2017-06-29 19:00:46	0|instagibbs|#meetingbegin
123 2017-06-29 19:00:59	0|wumpus|topics?
124 2017-06-29 19:01:00	0|morcos|i'd like to discuss the fee changes needed for 0.15
125 2017-06-29 19:01:06	0|sipa|i have a few topics
126 2017-06-29 19:01:17	0|instagibbs|morcos, ack
127 2017-06-29 19:01:20	0|sipa|short update on signature aggregation
128 2017-06-29 19:01:31	0|gribble|https://github.com/bitcoin/bitcoin/issues/10652 | Small step towards demangling cs_main from CNodeState by TheBlueMatt · Pull Request #10652 · bitcoin/bitcoin · GitHub
129 2017-06-29 19:01:35	0|gmaxwell|hurray for merges.
130 2017-06-29 19:01:45	0|sipa|the need for the watchonly rpc flag after multiwallet
131 2017-06-29 19:01:48	0|cfields|hi, here
132 2017-06-29 19:02:10	0|sipa|rolling utxo hashes
133 2017-06-29 19:02:23	0|wumpus|thanks for the topic suggestions, yes let's as usual start with high priority for review
134 2017-06-29 19:02:34	0|wumpus|#topic high priority for review
135 2017-06-29 19:02:35	0|wumpus|https://github.com/bitcoin/bitcoin/projects/8
136 2017-06-29 19:02:39	0|jonasschnelli|suggesting: again multiwallet endpoint vs json parameter
137 2017-06-29 19:03:09	0|wumpus|BlueMatt: instead of #10179?
138 2017-06-29 19:03:12	0|gribble|https://github.com/bitcoin/bitcoin/issues/10179 | Give CValidationInterface Support for calling notifications on the CScheduler Thread by TheBlueMatt · Pull Request #10179 · bitcoin/bitcoin · GitHub
139 2017-06-29 19:03:16	0|BlueMatt|correct
140 2017-06-29 19:03:18	0|kanzure|hi.
141 2017-06-29 19:03:22	0|BlueMatt|well, actually, its built on
142 2017-06-29 19:03:22	0|jonasschnelli|Replaced BlueMatt's 10179 with 10652
143 2017-06-29 19:03:24	0|BlueMatt|so...ehh
144 2017-06-29 19:03:30	0|BlueMatt|but, yea
145 2017-06-29 19:03:46	0|jonasschnelli|aha.. double pull binding strategy. :)
146 2017-06-29 19:04:04	0|BlueMatt|i mean 10179 is like one ack away, just want cfields to confirm i addressed his feedback sufficiently
147 2017-06-29 19:04:26	0|morcos|So I don't think I've had any there for a couple weeks, if I could add two?  It would be the first two of the fee changes, both have been open a little while, #10543 and #10589
148 2017-06-29 19:04:27	0|gribble|https://github.com/bitcoin/bitcoin/issues/10543 | Change API to estimaterawfee by morcos · Pull Request #10543 · bitcoin/bitcoin · GitHub
149 2017-06-29 19:04:28	0|gribble|https://github.com/bitcoin/bitcoin/issues/10589 | More economical fee estimates for RBF and RPC options to control by morcos · Pull Request #10589 · bitcoin/bitcoin · GitHub
150 2017-06-29 19:04:35	0|morcos|I apologize I have not been around to do more reviewing recently
151 2017-06-29 19:05:09	0|wumpus|BlueMatt: yes, as we discussed: it should still be merged, but it's no longer high-priority because you don't expect the dependent PR to get in in time to be safe for 0.15
152 2017-06-29 19:05:22	0|jonasschnelli|morcos: which one di you want to add to the high-prio list?
153 2017-06-29 19:05:30	0|jonasschnelli|*do
154 2017-06-29 19:05:32	0|wumpus|both
155 2017-06-29 19:05:56	0|jonasschnelli|Good
156 2017-06-29 19:05:56	0|morcos|both! :)  but i suppose 10589, if i can only have one
157 2017-06-29 19:06:01	0|BlueMatt|wumpus: well I want some glances at 10652 pre-15 to see if its too much or if it can go ahead...if its small enough for 15 I do want it for 15
158 2017-06-29 19:06:19	0|cfields|BlueMatt: yes, good enough. Will ACK it.
159 2017-06-29 19:06:20	0|jonasschnelli|We need both for 0.15
160 2017-06-29 19:06:21	0|BlueMatt|(since it fixes the kinda-not-a-big-deal provide-invalid-block attack thing)
161 2017-06-29 19:07:15	0|wumpus|ok - any other suggestions?
162 2017-06-29 19:07:24	0|wumpus|enough other topics otherwise
163 2017-06-29 19:07:40	0|wumpus|#topic short update on signature aggregation
164 2017-06-29 19:07:44	0|sipa|hi
165 2017-06-29 19:07:44	0|wumpus|(sipa)
166 2017-06-29 19:07:55	0|praxeology|Whats the status on the mempool data structure change?
167 2017-06-29 19:08:06	0|praxeology|woops not mempool
168 2017-06-29 19:08:08	0|sipa|this is just a status update of what gmaxwell, apoelstra and me have been working on lately
169 2017-06-29 19:08:09	0|praxeology|utxo
170 2017-06-29 19:08:11	0|wumpus|praxeology: you're interrupting a meeting
171 2017-06-29 19:08:32	0|sipa|i presented on this in milan, and later we wrote a paper for bitcoin17
172 2017-06-29 19:08:37	0|gmaxwell|praxeology: long since done.
173 2017-06-29 19:08:51	0|sipa|the paper was rejected with the very valuable feedback that a solution already existed
174 2017-06-29 19:09:06	0|sipa|namely a paper by Bellare & Neven from 2006
175 2017-06-29 19:09:43	0|sipa|it only solves one of the problems we were trying to solve (signature aggregation, not key aggregation)... but that's the only consensus-critical part if we'd want aggregation in bitcoin trnasactions
176 2017-06-29 19:09:54	0|gmaxwell|(which irritatingly never turned up in eons of searching for us)
177 2017-06-29 19:10:16	0|wumpus|so that solution is usable for bitcoin?
178 2017-06-29 19:10:19	0|sipa|yes
179 2017-06-29 19:10:25	0|sipa|the advantage is that this is peer-reviewed scheme with a strong security proof under very wide assumptions
180 2017-06-29 19:10:27	0|wumpus|nice!
181 2017-06-29 19:10:30	0|gmaxwell|Their solution is almost equivilent to ours (or is equivient with the right kind of squinting about hash function definitions).
182 2017-06-29 19:10:32	0|jonasschnelli|https://eprint.iacr.org/2006/285.pdf
183 2017-06-29 19:10:39	0|gmaxwell|so thats good too.
184 2017-06-29 19:11:09	0|wumpus|yes
185 2017-06-29 19:11:13	0|wumpus|good news
186 2017-06-29 19:11:17	0|gmaxwell|jonasschnelli: doesn't look like the right paper (though maybe its one they published to another venue)
187 2017-06-29 19:11:18	0|BlueMatt|cool!
188 2017-06-29 19:11:48	0|sipa|so what this scheme gives us is a way for transactions to have a single signature (as long as all signers cooperate, so even in the case of coinjoin) overall... regardless of the number of inputs or multisig
189 2017-06-29 19:11:52	0|wumpus|do we have a good link?
190 2017-06-29 19:12:08	0|sipa|https://cseweb.ucsd.edu/~mihir/papers/multisignatures-ccs.pdf
191 2017-06-29 19:12:15	0|sipa|^
192 2017-06-29 19:12:25	0|gmaxwell|^ thats it.
193 2017-06-29 19:12:27	0|wumpus|#link https://cseweb.ucsd.edu/~mihir/papers/multisignatures-ccs.pdf
194 2017-06-29 19:12:36	0|sipa|what it does not do is an ability to turn multisig into signle sig (but that could be added on top later, as it's purely a wallet interaction thing)
195 2017-06-29 19:12:43	0|sipa|it also supports batch validation
196 2017-06-29 19:12:54	0|cfields|ooh
197 2017-06-29 19:12:57	0|sipa|meaning that a whole block (or even multiple blocks) could be validated at once
198 2017-06-29 19:13:17	0|sipa|the speedup depends on the size of the batch, but may go as high as 5x (for 4000 signatures)
199 2017-06-29 19:13:21	0|gmaxwell|Unfortunately our paper isn't available because we need to update it to reflect that work,  but it is much more targeted for the Bitcoin application (and would probably be much more clear for people here).
200 2017-06-29 19:13:51	0|sipa|in the batch validation case (without aggregated signatures) the speedup would likely be restricted to 3.5x or so
201 2017-06-29 19:13:55	0|morcos|gmaxwell: is that something that'll happen?  can we just wait to read yours?
202 2017-06-29 19:14:09	0|sipa|yes, we'll definitely finish up the paper
203 2017-06-29 19:14:18	0|sipa|and discuss the change more widely
204 2017-06-29 19:14:25	0|sipa|just wanted to give a heads up here
205 2017-06-29 19:14:32	0|wumpus|yes, thanks for the update!
206 2017-06-29 19:14:38	0|morcos|if i could have next topic, i have to leave early
207 2017-06-29 19:14:41	0|cfields|sipa: what about that per-block aggregation that was briefly discussed? does this get us any closer to that?
208 2017-06-29 19:14:51	0|cfields|nm, will follow-up after meeting
209 2017-06-29 19:15:08	0|wumpus|morcos: what was your topic?
210 2017-06-29 19:15:14	0|gmaxwell|~2.3x speedup for 32 signatures in the aggregate, fwiw.
211 2017-06-29 19:15:18	0|morcos|Fee changes for 0.15
212 2017-06-29 19:15:28	0|wumpus|#topic fee changes needed for 0.15
213 2017-06-29 19:15:32	0|wumpus|morcos: sorry, missed that one
214 2017-06-29 19:15:51	0|wumpus|morcos: you were actually first to propose a topic :)
215 2017-06-29 19:16:05	0|morcos|I'll be relatively quick for my part, I think I've got all the PR's out now that I think need to go in for 0.15, but I want to encourage people to think about a bunch of the RPC API changes so they are good in their first release
216 2017-06-29 19:16:24	0|morcos|But the other thign is there is one piece of missing functionality wheich I think is needed
217 2017-06-29 19:16:36	0|morcos|#10590
218 2017-06-29 19:16:37	0|gribble|https://github.com/bitcoin/bitcoin/issues/10590 | Access to longer fee estimates using GUI · Issue #10590 · bitcoin/bitcoin · GitHub
219 2017-06-29 19:17:16	0|morcos|Given how volatile fee estimates are and how much they change between short targets and long, I think it's important to give the GUI access to longer fee estimates
220 2017-06-29 19:17:32	0|morcos|But someone more familar with QT can probably whip that up a lot quicker than me
221 2017-06-29 19:17:54	0|morcos|Might be best to build it on top of all my other changes, #10707 shoudl have everything in one
222 2017-06-29 19:17:55	0|gribble|https://github.com/bitcoin/bitcoin/issues/10707 | Better API for estimatesmartfee RPC by morcos · Pull Request #10707 · bitcoin/bitcoin · GitHub
223 2017-06-29 19:17:55	0|jonasschnelli|I'll have a look.
224 2017-06-29 19:18:13	0|morcos|Thanks!  That's what I was hoping for. :)  instagibbs might have more on this topic?
225 2017-06-29 19:18:21	0|instagibbs|#10333 for fee bug fix :)
226 2017-06-29 19:18:23	0|gribble|https://github.com/bitcoin/bitcoin/issues/10333 | [wallet] fee fixes: always create change, adjust value, and p… by instagibbs · Pull Request #10333 · bitcoin/bitcoin · GitHub
227 2017-06-29 19:18:37	0|instagibbs|not much else, maybe I'll summon energy to review your PRs
228 2017-06-29 19:18:39	0|morcos|is that the only thing you feel is critical for 0.15?
229 2017-06-29 19:18:47	0|instagibbs|only realistic merge yeah
230 2017-06-29 19:18:51	0|morcos|most of mine are now easy to review i think
231 2017-06-29 19:19:00	0|gmaxwell|Do we have a feel for when bump will be generally usable enough to start making replacability a default? (or at least more visible?)
232 2017-06-29 19:19:03	0|instagibbs|some of my other work has been sucked up by achow101 so waiting on 0.16 for that stuff
233 2017-06-29 19:19:54	0|morcos|gmaxwell: at least it'll be easily accessible to choose RBF given the RPC and GUI options in 0.15
234 2017-06-29 19:20:10	0|instagibbs|I'd really like it to be able to add additional inputs as needed
235 2017-06-29 19:20:13	0|gmaxwell|Oh!  I often miss gui changes, I'll check that out.
236 2017-06-29 19:20:20	0|jonasschnelli|Yes. Not sure if we persist the RBF state across restarts (in the GUI)
237 2017-06-29 19:20:21	0|morcos|Might help us learn if there are other bump features needed...
238 2017-06-29 19:20:24	0|instagibbs|but it seems to me the logic is much simpler with effective value....
239 2017-06-29 19:20:27	0|jonasschnelli|Ideally we should
240 2017-06-29 19:20:29	0|instagibbs|some disagree
241 2017-06-29 19:20:44	0|gmaxwell|instagibbs: IIRC that was the big usability blocker for further use.
242 2017-06-29 19:21:06	0|wumpus|gmaxwell: https://github.com/bitcoin/bitcoin/pull/9527#issuecomment-311659024
243 2017-06-29 19:21:10	0|instagibbs|it randomly doesn't work which is disappointing UX
244 2017-06-29 19:21:20	0|morcos|gmaxwell: the ability to addother inputs?  isn't it pretty rare to not have change?
245 2017-06-29 19:21:45	0|jonasschnelli|But can happen...
246 2017-06-29 19:21:46	0|wumpus|no, we don't persist RBF state, it has to be selected per transaction
247 2017-06-29 19:22:03	0|instagibbs|morcos, we are going to target more exact matches in future, fwiw
248 2017-06-29 19:22:03	0|jonasschnelli|wumpus: maybe the GUI should remember it
249 2017-06-29 19:22:04	0|wumpus|the only way to make it persist is the command line option
250 2017-06-29 19:22:15	0|morcos|wumpus: the gui initializes with the the command line argument, and then persists during the session
251 2017-06-29 19:22:16	0|wumpus|jonasschnelli: meh, better to have it as "option" then
252 2017-06-29 19:22:25	0|gmaxwell|FWIW, I believe electrum defaults to replacable now and pushes pretty hard in that direction, though users can flip it off on a per tx basis.
253 2017-06-29 19:22:30	0|morcos|via checkbox
254 2017-06-29 19:22:47	0|wumpus|jonasschnelli: persisting non-option settings between restarts would be unexpected
255 2017-06-29 19:23:03	0|jonasschnelli|Yes. I guess your right..
256 2017-06-29 19:23:04	0|gmaxwell|In any case, I think the default is kind of moot until bumping is sufficiently mature.
257 2017-06-29 19:23:22	0|wumpus|between transactions in the same session makes sense I guess
258 2017-06-29 19:23:25	0|morcos|I suppose I have one more question on that
259 2017-06-29 19:23:32	0|jonasschnelli|Yes. If the bump won't work because it can't add another input the default should remain at the current state
260 2017-06-29 19:23:37	0|wumpus|yes
261 2017-06-29 19:23:52	0|jonasschnelli|It can happen quickly when fees are rising
262 2017-06-29 19:24:00	0|achow101|hi. I'm late
263 2017-06-29 19:24:02	0|morcos|Right now there are no options to the "Increase transaction fee" option in the GUI and it uses the default tx confirm target.  Should it instead use whatever the slider is set to?
264 2017-06-29 19:24:20	0|jonasschnelli|Yes
265 2017-06-29 19:24:20	0|morcos|If the slider is not in use and custom fee is set, shoudl it use that?
266 2017-06-29 19:24:23	0|wumpus|morcos: the slider is on another tab
267 2017-06-29 19:24:25	0|jonasschnelli|I'd like to work on the replacability in the GUI for 0.16
268 2017-06-29 19:24:32	0|morcos|Those would be easy changes to make after my PR
269 2017-06-29 19:24:40	0|BlueMatt|the slider is in another tab, thats strange
270 2017-06-29 19:24:47	0|wumpus|morcos: not sure that would be intuitive, people assume the slider is for new transactions, the bump option should probably have its own choice dialog
271 2017-06-29 19:24:51	0|jonasschnelli|First I though of bringing back to tx to the original send-tx screen (you could even add recipients... ) but meh
272 2017-06-29 19:25:02	0|morcos|wumpus: that seems maybe too much optionality
273 2017-06-29 19:25:09	0|jonasschnelli|The bump window should just be lager and has the slider
274 2017-06-29 19:25:17	0|wumpus|jonasschnelli: yes
275 2017-06-29 19:25:28	0|morcos|ok, thats fine.. so leave it as the wallet default confirm target for now?
276 2017-06-29 19:25:35	0|wumpus|yes
277 2017-06-29 19:25:42	0|BlueMatt|yea, sucks, but its easy and reasonable
278 2017-06-29 19:25:48	0|jonasschnelli|And also we have never really discussed the pre-signed bumps.. but that we should probably do in another meeting
279 2017-06-29 19:25:58	0|BlueMatt|yea, that sounds like a 16
280 2017-06-29 19:26:00	0|instagibbs|jonasschnelli, that will involve new strategy
281 2017-06-29 19:26:01	0|instagibbs|:)
282 2017-06-29 19:26:17	0|instagibbs|reasonably diff from after the fact fix imo
283 2017-06-29 19:26:43	0|jonasschnelli|I'd say focus on fee opt. in 0.15, rbf in 0.16
284 2017-06-29 19:27:16	0|wumpus|agreed
285 2017-06-29 19:27:22	0|wumpus|#topic the need for the watchonly rpc flag after multiwallet (sipa)
286 2017-06-29 19:27:27	0|sipa|hi!
287 2017-06-29 19:27:38	0|wumpus|(we need to move forward a bit, lots of topics)
288 2017-06-29 19:27:44	0|jonasschnelli|is that similar to the -disablehot?
289 2017-06-29 19:27:44	0|sipa|currently many RPCs have an optional flag "include watchonly"
290 2017-06-29 19:28:15	0|sipa|at the time the need for that flag existed because of a desire to keep your "hot" wallet separated from your "watch only" wallet
291 2017-06-29 19:28:21	0|sipa|i think that was a mistake
292 2017-06-29 19:28:25	0|wumpus|disablehot: #9662
293 2017-06-29 19:28:26	0|gribble|https://github.com/bitcoin/bitcoin/issues/9662 | Add `-disablehot` mode: a sane mode for watchonly-wallets by jonasschnelli · Pull Request #9662 · bitcoin/bitcoin · GitHub
294 2017-06-29 19:28:41	0|wumpus|sipa: yes, on the long term I agree with you
295 2017-06-29 19:28:51	0|jonasschnelli|sipa: you think with multiwallet the wallet should either be watch or hot?
296 2017-06-29 19:28:56	0|sipa|jonasschnelli: no
297 2017-06-29 19:29:03	0|wumpus|sipa: makes more sense to have a wallet either full-watchonly or has-keys
298 2017-06-29 19:29:16	0|sipa|wumpus: perhaps, but that's orthogonal
299 2017-06-29 19:29:23	0|wumpus|sipa: I don't understand you then
300 2017-06-29 19:29:25	0|BlueMatt|why is that a mistake?
301 2017-06-29 19:29:25	0|instagibbs|ok get to the point :)
302 2017-06-29 19:29:33	0|jonasschnelli|Let sipa explain...
303 2017-06-29 19:29:34	0|sipa|what i'm trying to get at is that the within-a-wallet separation is no longer needed
304 2017-06-29 19:29:51	0|wumpus|how is that different from what I said?
305 2017-06-29 19:30:12	0|wumpus|instead of watchonly within a wallet you'd have a watchonly wallet and a normal wallet
306 2017-06-29 19:30:18	0|sipa|i'm not arguing to remove the ability to have both keys and watchonly in one wallet
307 2017-06-29 19:30:19	0|gmaxwell|because if you want to have a mixed thing thats fine too, then you just have a mixed thing. No need to flag, if you want seperation, use two wallets.
308 2017-06-29 19:30:20	0|jonasschnelli|but I fail to see the difference then between only allowing watch-only or hot
309 2017-06-29 19:30:33	0|sipa|just that there is no need to just select coins that affect one part
310 2017-06-29 19:30:39	0|gmaxwell|you're suggesting an extra restriction.
311 2017-06-29 19:30:39	0|sipa|or see a 'balance' of just one part
312 2017-06-29 19:30:52	0|sipa|a wallet is a wallet, and has a single balance
313 2017-06-29 19:31:01	0|sipa|some of the keys may require decrypting your wallet
314 2017-06-29 19:31:05	0|wumpus|oh, right
315 2017-06-29 19:31:07	0|sipa|some of the keys may require a hardware wallet
316 2017-06-29 19:31:18	0|jonasschnelli|I see... yes.
317 2017-06-29 19:31:22	0|sipa|some of the key may be just watchonly and you need to use raw transactions to interact with thing
318 2017-06-29 19:31:27	0|BlueMatt|fair, this sounds like an 0.17 or 0.18 thing, though
319 2017-06-29 19:31:31	0|gmaxwell|Now, logically you probably will seperate or something, for convience, but I don't see a particular reason to require that right now.
320 2017-06-29 19:31:33	0|BlueMatt|are you asking if we should deprecate?
321 2017-06-29 19:31:33	0|sipa|i was hoping 0.15
322 2017-06-29 19:31:34	0|wumpus|BlueMatt: agree, long term
323 2017-06-29 19:31:47	0|sipa|just make the watchonly flag ignored and always set it to true
324 2017-06-29 19:31:50	0|wumpus|this is not something we're going to change in the RPC interface pre-0.15
325 2017-06-29 19:31:55	0|sipa|ok
326 2017-06-29 19:31:56	0|wumpus|peopel rely on this
327 2017-06-29 19:32:02	0|wumpus|we could document it as deprecated
328 2017-06-29 19:32:04	0|BlueMatt|we'd need to mark it deprecated
329 2017-06-29 19:32:05	0|morcos|sipa: that seems reasonable except what about identifying which things you have keys for and which you dont..
330 2017-06-29 19:32:12	0|BlueMatt|probably deprecate after we have working multiwallet that is stable
331 2017-06-29 19:32:19	0|wumpus|then remove the flag for 0.16 or 0.17, but this seems over-hurried
332 2017-06-29 19:32:21	0|BlueMatt|so maybe deprecate in 0.16...
333 2017-06-29 19:32:25	0|morcos|that seems a useful distinction to keep to me
334 2017-06-29 19:32:26	0|gmaxwell|with 0.15 and multiwallet we can start deprication at least-- e.g. advise that this will happen in the future, suggest people use seperate wallets. . The one problem with that however is that your seperate watchonly wallet still needs the stupid flag everywhere. :(
335 2017-06-29 19:32:27	0|BlueMatt|remove in 17 or 18
336 2017-06-29 19:32:47	0|wumpus|let's focus on actually getting multiwallet into 0.15
337 2017-06-29 19:32:49	0|instagibbs|related topic: some way to signal that the funds are "safe" when you expect a hardware wallet to have the privkey
338 2017-06-29 19:32:49	0|jonasschnelli|I somehow think mixed wallets can be a footgun source... but right, it orthogonal
339 2017-06-29 19:32:53	0|instagibbs|post-0.15 ofc
340 2017-06-29 19:32:58	0|sipa|maybe i haven't made this clear, but how do you deal with hardware wallets, for example?
341 2017-06-29 19:33:07	0|jonasschnelli|we need a standard!
342 2017-06-29 19:33:09	0|morcos|+1 better support for hardware wallets!
343 2017-06-29 19:33:09	0|sipa|add a 2nd option everyone 'include hw wallet keys'
344 2017-06-29 19:33:15	0|sipa|jonasschnelli: orthogonal
345 2017-06-29 19:33:18	0|wumpus|hardware wallets in bitcoin core is a different topic
346 2017-06-29 19:33:23	0|BlueMatt|we dont need to add a flag for hw wallets
347 2017-06-29 19:33:31	0|sipa|BlueMatt: then why do we need a flag for watchonly?
348 2017-06-29 19:33:36	0|wumpus|important, but certainly not one that's going to make it into 0.15
349 2017-06-29 19:33:39	0|BlueMatt|we can say "hw wallets are always included in balance, flag for watchonly is deprecated" starting in the version that supports hw wallets
350 2017-06-29 19:33:40	0|gmaxwell|sipa is pointing out that the model of 'watch only' when applied to also having hardware wallets starts adding combinitoric blowup.
351 2017-06-29 19:33:54	0|sipa|BlueMatt: fair enough
352 2017-06-29 19:34:02	0|jonasschnelli|If a wallet has no clear cur between hot and cold (watch-only), a code-level guarantee, I would not use it for hot funds...
353 2017-06-29 19:34:03	0|BlueMatt|yes, agreed, we should not make it worse, but we dont need to worry about this until at least 16, I think
354 2017-06-29 19:34:07	0|jonasschnelli|*cut
355 2017-06-29 19:34:15	0|BlueMatt|need useable working good multiwallet first, which likely wont be 15
356 2017-06-29 19:34:15	0|wumpus|agree on not making it worse
357 2017-06-29 19:34:19	0|gmaxwell|BlueMatt: thats a point. now just give me a flag for importmulti that gives me a watching key imported that way and it's good to go. :P
358 2017-06-29 19:34:20	0|sipa|jonasschnelli: again, orthogonal
359 2017-06-29 19:34:35	0|instagibbs|I have a working Core+Ledger system, and have a couple thoughts, but this is a different topic yep
360 2017-06-29 19:34:40	0|gmaxwell|BlueMatt: uhh, it's like done.
361 2017-06-29 19:34:51	0|jonasschnelli|sipa: but why not just separating pure watch-only wallets from hot wallets? Why would that be orthogonal?
362 2017-06-29 19:35:04	0|BlueMatt|gmaxwell: I know, but we need a cycle of finding more use-cases and making sure we've got it all covered, was my piont
363 2017-06-29 19:35:12	0|wumpus|yes multiwallet is almost done, but in 0.15 it will at least be experimental
364 2017-06-29 19:35:16	0|BlueMatt|eg createwallet flows within rpc, disconectwallet, etc
365 2017-06-29 19:35:17	0|sipa|jonasschnelli: "orthogonal" means you can still do that
366 2017-06-29 19:35:23	0|sipa|jonasschnelli: it has nothing to do with this issue
367 2017-06-29 19:35:25	0|wumpus|it's the first release it is in, after all
368 2017-06-29 19:35:28	0|gmaxwell|jonasschnelli: because that is an additional restriction that AFAIK isn't needed. maybe later its needed to not support mixed but it seems like a seperate issue to me.
369 2017-06-29 19:35:47	0|jonasschnelli|Okay
370 2017-06-29 19:36:02	0|BlueMatt|ok, so we all agree, eventually push people towards multiwallet away from watchonly :)
371 2017-06-29 19:36:06	0|BlueMatt|next topic? :p
372 2017-06-29 19:36:07	0|sipa|what i want to get add is that a wallet is just a collection of keys it considers "mine" - independent of its ability to actually fully sign
373 2017-06-29 19:36:13	0|sipa|BlueMatt: yes, agree
374 2017-06-29 19:36:20	0|wumpus|#topic rolling utxo hashes
375 2017-06-29 19:36:23	0|sipa|hi!
376 2017-06-29 19:36:23	0|wumpus|(sipa again)
377 2017-06-29 19:36:30	0|instagibbs|sipa, ISMINE_* tho :)
378 2017-06-29 19:36:35	0|instagibbs|ok next topic
379 2017-06-29 19:36:55	0|sipa|with pertxout we changed the serialized_hash because the new format no longer maintains the tx version of the utxo
380 2017-06-29 19:37:12	0|sipa|i posted about rolling utxo hashes a while ago on the ML
381 2017-06-29 19:37:36	0|sipa|i'm not proposing actually implementing that, but would it be worthwhile to immediately switch to a scheme that is compatible with it?
382 2017-06-29 19:37:44	0|sipa|so that there is no need to break the API again
383 2017-06-29 19:38:02	0|gmaxwell|sipa: as in don't do the rolling thing, but have the oneshot thing compute the same hash?
384 2017-06-29 19:38:06	0|sipa|yes
385 2017-06-29 19:38:17	0|sipa|downside: makes gettxoutsetinfo slower
386 2017-06-29 19:38:31	0|wumpus|how much slower?
387 2017-06-29 19:38:33	0|sipa|upside: allows us to make gettxoutsetinfo super fast in the future
388 2017-06-29 19:38:42	0|gmaxwell|lots slower.
389 2017-06-29 19:38:45	0|sipa|several times
390 2017-06-29 19:38:57	0|wumpus|could add a new RPC for it
391 2017-06-29 19:39:02	0|gmaxwell|sipa: Well a challenge there is that I'm not sure that we've settled on the field. So that isn't a guarentee of compatiblity.
392 2017-06-29 19:39:04	0|wumpus|instead of gettxoutsetinfo
393 2017-06-29 19:39:27	0|sipa|interesting, i hadn't considered that
394 2017-06-29 19:39:31	0|sipa|gmaxwell: yeah, i know
395 2017-06-29 19:39:47	0|gmaxwell|actually if we drop the hash from gettxoutsetinfo i think thats the only thing now that requires scanning the whole thing.
396 2017-06-29 19:39:56	0|sipa|no, everything does
397 2017-06-29 19:40:02	0|sipa|(txout count etc)
398 2017-06-29 19:40:03	0|wumpus|yes it's all aggregate statistics
399 2017-06-29 19:40:07	0|gmaxwell|yes but it wouldn't have to with rather trivial changes.
400 2017-06-29 19:40:08	0|sipa|though those things can be maintained on the fly
401 2017-06-29 19:40:21	0|gmaxwell|which would be robust and wouldn't change.
402 2017-06-29 19:40:28	0|sdaftuar|i think we will want an RPC that can scan the disk to calculate the answer, even if we are able to calculate everything on the fly
403 2017-06-29 19:40:35	0|sdaftuar|so that we know our on-disk data is correct
404 2017-06-29 19:40:36	0|sipa|sdaftuar: good point
405 2017-06-29 19:40:40	0|gmaxwell|sdaftuar: restart your node. :P
406 2017-06-29 19:41:03	0|sipa|an advantage of the fast hash is that you can compare it with a recompute-the-whole-thing
407 2017-06-29 19:41:18	0|gmaxwell|okay interesting points.
408 2017-06-29 19:41:18	0|wumpus|that'd be very nice
409 2017-06-29 19:41:45	0|wumpus|a utxo hash that would be quick to compute for every block would be very nice to have
410 2017-06-29 19:42:21	0|gmaxwell|(I was momentarily overestimating how easy it would be to switch to summary statistics, I forgot that they have to be saved and loaded across restart... or otherwise every startup needs the equal of a stats call)
411 2017-06-29 19:43:04	0|gmaxwell|wumpus: right thats the goal of pieter's work. It's just a bit immature now, and if we implmenet it at the moment we may want to switch to an incompatible version later.
412 2017-06-29 19:43:40	0|wumpus|I like to check that all my nodes have the same utxo hash, but calling getutxosetinfo for every block takes too much time, I've tried and given up :)
413 2017-06-29 19:43:53	0|gmaxwell|Assuming we stay with the multiplicative group hash,  we need to pick a prime where multiplication mod that prime is as fast as possible.  Sipa has done some work there, but it's a research project that can sink as much time as we want to put into it.
414 2017-06-29 19:44:32	0|sipa|or we could just use the elliptic curve version, which can probably be made ~2 slower than the GMP-based MuHash
415 2017-06-29 19:44:38	0|sipa|which is just a few lines of code
416 2017-06-29 19:44:58	0|wumpus|now doing it intermittently, but that means that when it fails we don't know exacly where it started to diverge
417 2017-06-29 19:45:18	0|gmaxwell|right, I want to have UpdateTip log the value.
418 2017-06-29 19:45:23	0|sipa|^ that
419 2017-06-29 19:45:31	0|sdaftuar|wumpus: it's actually not clear to me how much the fast utxo hash calculation helps in comparing running nodes
420 2017-06-29 19:46:12	0|sipa|well the fast utxo hash lets you do a consistency check on just a single node
421 2017-06-29 19:46:31	0|sdaftuar|but what is exactly being compared as consistent?
422 2017-06-29 19:46:33	0|sipa|by having a fast incrementally-updated version, and a slow recompute-from-scratch one
423 2017-06-29 19:46:34	0|gmaxwell|sdaftuar: because you can log the utxo hash at each point, and so if they diverge in a way that the hash sees (e.g. not underlying disk corruption) you'll learn.   Also you could run a command that checks the disk against the running value to catch that disk corrouption.
424 2017-06-29 19:46:57	0|gmaxwell|so  your disk <> your running <> my running <> my disk
425 2017-06-29 19:47:14	0|sdaftuar|yes, i agree if you do the comparison with disk, then you get something valuable
426 2017-06-29 19:47:26	0|sdaftuar|but just comparing the fast calculation between nodes doesn't seem like it does much, does it?
427 2017-06-29 19:47:29	0|wumpus|hm yes good point
428 2017-06-29 19:47:32	0|gmaxwell|right now it is a PITA to compare you and I at disk because we have to do it at the same time (and hope there isn't a block at that instant. :P )
429 2017-06-29 19:47:41	0|sdaftuar|gmaxwell: agreed
430 2017-06-29 19:47:47	0|gmaxwell|sdaftuar: it depends on where the errors you're concerned about are happening.
431 2017-06-29 19:48:24	0|wumpus|gmaxwell: yes, even when you time the RPC command on blocknotify, it sometimes misses the block :)
432 2017-06-29 19:48:32	0|gmaxwell|if they're below the layer where the running hash runs you only gain if you also do periodic checks between it and the disk.  Above it, however, you have constant checking.
433 2017-06-29 19:49:09	0|gmaxwell|but the nice thing is that disk and running can be async checked... You and I don't need to do our disk comparisons at the same time.
434 2017-06-29 19:49:37	0|wumpus|indeed
435 2017-06-29 19:49:50	0|gmaxwell|sdaftuar: this is all also machinery we almost certantly need for a reasonable UTXO-assume-valid kind of sync in the future.
436 2017-06-29 19:49:56	0|wumpus|all in all a rolling utxo hash is an improvement, it creates more options, but you can still do the same as now if you want
437 2017-06-29 19:50:04	0|sdaftuar|gmaxwell: yeah i agree and that's the use case i'm most excited about :)
438 2017-06-29 19:50:20	0|sdaftuar|i was just trying to figure out exactly how i'd use to compare my own nodes, and wasn't sure of the utility
439 2017-06-29 19:50:45	0|gmaxwell|wumpus: the challange though is that it isn't free. muhash on the whole utxo set takes CPU minutes.
440 2017-06-29 19:51:02	0|wumpus|gmaxwell: yes I'm not sure it should replace the faster hash
441 2017-06-29 19:51:16	0|wumpus|maybe it should justb e an additional thing
442 2017-06-29 19:51:24	0|gmaxwell|well once it's a running hash its very fast. :P
443 2017-06-29 19:51:41	0|sdaftuar|hash_serialized_3? :P
444 2017-06-29 19:51:42	0|wumpus|OTOH we're already breaking the hash for 0.15
445 2017-06-29 19:51:57	0|wumpus|(which is kind of sad, as it makes it impossible to compare against older versions)
446 2017-06-29 19:52:33	0|gmaxwell|sipa backported the new hash to the old system for development testing, FWIW.
447 2017-06-29 19:52:54	0|gmaxwell|(it's a pretty trivial change, IIRC, just drop the version from it)
448 2017-06-29 19:53:04	0|wumpus|cool, that'd be useful, especially with the 0.14 to 0.15 database change it's important to be able to check synchronization
449 2017-06-29 19:54:06	0|gmaxwell|This patch existed at one point already, dunno if sipa still has it.
450 2017-06-29 19:54:08	0|sipa|the problem is that #10434 is quite a bit of intricate code
451 2017-06-29 19:54:09	0|gribble|https://github.com/bitcoin/bitcoin/issues/10434 | [WIP] 3072-bit MuHash based hash_serialized by sipa · Pull Request #10434 · bitcoin/bitcoin · GitHub
452 2017-06-29 19:54:44	0|sipa|the EC version would be many times less code (given that we already have secp256k1), but be a few times slower
453 2017-06-29 19:55:37	0|wumpus|I don't have a strong opinion on it
454 2017-06-29 19:55:38	0|sipa|on the other hand, MuHash is very simple to implement in anything that already has big integers (it's a few lines in python)
455 2017-06-29 19:55:59	0|sipa|ok
456 2017-06-29 19:56:07	0|wumpus|though in general I'd say higher performance seems preferable to the ability to re-use code
457 2017-06-29 19:56:23	0|sipa|in that case, some review would be welcome :)
458 2017-06-29 19:56:33	0|wumpus|but I haven't seen the code
459 2017-06-29 19:56:42	0|wumpus|yeah, hope to get around to it
460 2017-06-29 19:57:00	0|sipa|i can drop the asm optimized version from the first PR if wanted
461 2017-06-29 19:57:07	0|praxeology|Couldn't you put a delay on insert/remove from the rolling hash... say only for utxos that are 1 day of blocks old? isn't a hash for N blocks ago just about as good as the current hash?
462 2017-06-29 19:57:19	0|sipa|praxeology: totally irrelevant
463 2017-06-29 19:57:44	0|sipa|that would mean you need to keep those utxos around for processing later
464 2017-06-29 19:58:00	0|sipa|we have an approach that can combine them into a running hash in _microseconds_
465 2017-06-29 19:58:07	0|gmaxwell|All doing that does is perhaps saves you 1% of computation for blocks that are reorged out but at the expense of complexifying everything because the data is inconsistently available.
466 2017-06-29 19:58:30	0|praxeology|What percent of utxos are spent within a day?
467 2017-06-29 19:58:38	0|instagibbs|2 minutes left
468 2017-06-29 19:58:42	0|instagibbs|if anyone has microtopic
469 2017-06-29 19:58:43	0|wumpus|that seems irrelevant to this discussion
470 2017-06-29 19:58:55	0|wumpus|(although it's interesting to know in its own right)
471 2017-06-29 19:59:07	0|praxeology|Sounds like you guys are concerned about performance on the rolling hash
472 2017-06-29 19:59:25	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-06-29-19.00.log.html
473 2017-06-29 19:59:25	0|lightningbot|Meeting ended Thu Jun 29 19:59:24 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
474 2017-06-29 19:59:25	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-06-29-19.00.html
475 2017-06-29 19:59:25	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-06-29-19.00.txt
476 2017-06-29 19:59:25	0|wumpus|#endmeeting
477 2017-06-29 19:59:32	0|gmaxwell|praxeology: delaying it doesn't change that.
478 2017-06-29 19:59:33	0|instagibbs|sipa, you still around?
479 2017-06-29 19:59:37	0|sipa|instagibbs: sure
480 2017-06-29 19:59:46	0|instagibbs|ok let me toss a wallet q to you
481 2017-06-29 19:59:54	0|gmaxwell|praxeology: its the same amount of computation if you do it now or 100 blocks ago.
482 2017-06-29 20:00:00	0|midnightmagic|Man I wish people would end meetings elsewhere with that kind of precision..
483 2017-06-29 20:00:04	0|wumpus|yes it'd just move the computation in time
484 2017-06-29 20:00:23	0|wumpus|midnightmagic: I guess they should hire me as meeting chair :p
485 2017-06-29 20:00:28	0|praxeology|gmaxwell:  delaying will reduce the number of things that are xored (err whatever math op you doing), since utxos that were spent before the delay window are never added
486 2017-06-29 20:00:30	0|gmaxwell|praxeology: if you imagine something which is never consistent with any actual state of the system, then that really isn't all that useful.
487 2017-06-29 20:00:37	0|BlueMatt|I was gonna say something about the swiss leading the meeting, but its wumpus, not jonasschnelli
488 2017-06-29 20:00:42	0|instagibbs|sipa, so for hw wallets, would it be reasonable to have a new ISMINE type that means the wallet expects the output to be spendable by the wallet even though privkeys aren't physically present in the wallet.dat
489 2017-06-29 20:00:58	0|sipa|instagibbs: in my opinion, ISMINE should become a bool
490 2017-06-29 20:01:04	0|sipa|it's yours or not
491 2017-06-29 20:01:07	0|gmaxwell|praxeology: that isn't delayed.
492 2017-06-29 20:01:09	0|instagibbs|ah ok, so no
493 2017-06-29 20:01:15	0|midnightmagic|wumpus: :-)  Your nickname shall be The Guillotine
494 2017-06-29 20:01:19	0|instagibbs|well in that case at least some of the logic could be moved elsewhere
495 2017-06-29 20:01:23	0|sipa|instagibbs: the ability to spend should be independent from what is considered yours
496 2017-06-29 20:01:31	0|sipa|instagibbs: (note, that's my personal opinion)
497 2017-06-29 20:01:43	0|gmaxwell|praxeology: I believe what you are suggesting doing is computing it sparsely so that there isn't a value computed at every block.
498 2017-06-29 20:01:44	0|wumpus|midnightmagic: :-)
499 2017-06-29 20:01:46	0|instagibbs|no it's fair, I'm just trying to get my wallet to understand what I consider mine
500 2017-06-29 20:01:50	0|instagibbs|and right now it's janky mess
501 2017-06-29 20:02:06	0|sipa|instagibbs: perhaps the solvable distinction is still useful
502 2017-06-29 20:02:30	0|instagibbs|so a new "consider yours" function would fix my current issue in a cleaner way
503 2017-06-29 20:02:49	0|sipa|cfields: still around?
504 2017-06-29 20:02:52	0|achow101|instagibbs: isn't there some combination of ISMINE_ types that indicate "no privkey in wallet but I can still spend it"
505 2017-06-29 20:02:53	0|gmaxwell|praxeology: this would reduce computation somewhat, but at the expense creating coordination points... and then you only perhaps get a 2x speedup, but you also add bursts of letency rather than being able to compute it continually.
506 2017-06-29 20:02:58	0|cfields|sipa: yes
507 2017-06-29 20:03:01	0|praxeology|gmaxwell: I'm suggesting only adding a utxo to the hash on the 144th confirmation
508 2017-06-29 20:03:28	0|instagibbs|achow101, there is solvable+watchonly
509 2017-06-29 20:03:32	0|instagibbs|but that doesn't mean you can spend it
510 2017-06-29 20:03:38	0|gmaxwell|praxeology: that would make something which is _never_ consistent with the utxo set at any point, I think this would be completely useless to us.
511 2017-06-29 20:03:49	0|instagibbs|so if you have a hw wallet, you expect to be able to sign for it, but there's no enum for it
512 2017-06-29 20:03:55	0|gmaxwell|praxeology: it couldn't be used to check database consistency, it couldn't be used to perform a sync from utxo.
513 2017-06-29 20:04:08	0|sipa|praxeology: that sort of approach may be useful for UTXO/TXO commitment like approaches, where updating the commitment is very expensive and cheaper when batched
514 2017-06-29 20:04:09	0|instagibbs|so in corner cases you consider that output untrusted, and get "insufficient amount"
515 2017-06-29 20:04:23	0|sipa|praxeology: but the rolling UTXO idea was specifically intended to not need that, because it's so fast
516 2017-06-29 20:04:30	0|praxeology|gmaxwell: if you have the last 144 blocks then you can do the remainder of the utxos from those blocks to finish the hash at a particular point
517 2017-06-29 20:04:34	0|achow101|instagibbs: oh
518 2017-06-29 20:04:48	0|bitcoin-git|[13bitcoin] 15narula opened pull request #10708: Connecttrace fewer blocks (06master...06connecttrace-fewer-blocks) 02https://github.com/bitcoin/bitcoin/pull/10708
519 2017-06-29 20:05:02	0|sipa|praxeology: just looking up a utxo spent from disk is more work than updating the hash
520 2017-06-29 20:05:18	0|cfields|neha__: eh? :)
521 2017-06-29 20:05:20	0|instagibbs|achow101, I coded a fix for this corner issue, but only for p2sh multisig... current methodology kind of forces me to do janky fix or make another ismine enum :/
522 2017-06-29 20:06:13	0|praxeology|sipa: yes, well not sure the use case of when such would be needed
523 2017-06-29 20:06:16	0|achow101|just make ismine a bool :p
524 2017-06-29 20:08:18	0|praxeology|earlier you guys were talking about a tx just having one signature, even for multiple things that need to be signed.  You talked about computation performance.  What about impact on tx size?
525 2017-06-29 20:08:46	0|praxeology|particularly since... i hear that network bandwidth is the main bottlneck
526 2017-06-29 20:09:24	0|instagibbs|N signatures in 1 signature space possible, across inputs. Still need the pubkeys
527 2017-06-29 20:11:20	0|praxeology|sure, still need public keys.  but what about the signature size?
528 2017-06-29 20:11:43	0|neha|cfields: BlueMatt gave me an issue to fix!
529 2017-06-29 20:11:47	0|sipa|64 bytes instead of N*72
530 2017-06-29 20:11:48	0|sipa|praxeology: ^
531 2017-06-29 20:11:54	0|gmaxwell|praxeology: instagibbs said: one signature.
532 2017-06-29 20:12:29	0|sipa|praxeology: and bandwidth isn't all that much of a factor anymore single compact blocks etc
533 2017-06-29 20:12:32	0|cfields|neha: good to see! that's a rabbit hole. I'd be nervous if you didn't find more things to fix while you're down there :)
534 2017-06-29 20:12:41	0|instagibbs|achow101, sounds simple, but let's see all the interaction with current wallet stuff
535 2017-06-29 20:12:48	0|gmaxwell|(the signatures in bitcoin today are 72 instead of 64.125 just because they use a dumb encoding.
536 2017-06-29 20:13:06	0|gmaxwell|)
537 2017-06-29 20:13:44	0|praxeology|sipa: do you have a layman link for "single compact block"? or anyone?
538 2017-06-29 20:13:53	0|sipa|praxeology: bip 152
539 2017-06-29 20:14:12	0|sipa|i'm sure there are better explanation online than the bip, though
540 2017-06-29 20:14:21	0|gmaxwell|I dunno the bit is pretty good.
541 2017-06-29 20:14:27	0|gmaxwell|bip
542 2017-06-29 20:14:39	0|instagibbs|gmaxwell, speaking of which how is 0.5RTT going these days, any change?
543 2017-06-29 20:14:54	0|instagibbs|(if you're monitoring)
544 2017-06-29 20:14:54	0|sipa|cfields: so the block-wide aggregation that adiabat proposed a while ago on the ML still applies to Bellare-Neven... allowing to have only 32 bytes of the signature in every tx, and another 32 byte block wide
545 2017-06-29 20:15:07	0|sipa|cfields: the downside is that it doesn't play nicely with cached signature validation
546 2017-06-29 20:15:19	0|gmaxwell|instagibbs: meh, we need the skip-recent-txn things in mining.  It's gone up and down (in particular utility of the extrapool has gone up and down)
547 2017-06-29 20:15:24	0|sipa|cfields: as wtxids would change after inclusion in a block
548 2017-06-29 20:15:45	0|gmaxwell|instagibbs: during periods of long backlogs the extrapool is too small-- I see misses that my node had seen before.
549 2017-06-29 20:16:34	0|cfields|sipa: hmm. Does parallel validation still apply as well?
550 2017-06-29 20:16:40	0|praxeology|sipa: oh, that is just where txs are not re-relayed with blocks.  Something  like a 1/2 bandwidth used improvement.
551 2017-06-29 20:16:51	0|cfields|*the parallel validation improvements
552 2017-06-29 20:17:04	0|praxeology|or is there something else I missed when skimming? something on the order of mimblewimble improvement?
553 2017-06-29 20:17:19	0|sipa|praxeology: yes, but the bandwidth needed to propagate a block quickly is massively reduced
554 2017-06-29 20:17:27	0|sipa|praxeology: overall data volume is reduced by 2
555 2017-06-29 20:17:42	0|gmaxwell|praxeology: typically at the tip blocks are transmitted with about 16kbytes.
556 2017-06-29 20:18:09	0|sipa|cfields: yes
557 2017-06-29 20:18:30	0|sipa|cfields: you can just shard and do the computation for a number of groups
558 2017-06-29 20:18:45	0|sipa|and then do a simple cheap combine operation
559 2017-06-29 20:19:08	0|gmaxwell|you lose some of the asymtoptic gains though we've been expirementing with parallel versions of the aggregate validation operation.
560 2017-06-29 20:20:31	0|gmaxwell|instagibbs: in the last 144 blocks I see 23% requiring a round trip. 13% were saved from needing one by the extra pool.  A week ago the extrapool saves were about half that I think.
561 2017-06-29 20:22:43	0|cfields|sipa: if we cached as much as possible otherwise (hashing mainly, i suppose) and completely dropped the pre-validated cache, do you have a sense of how it'd compare? I realize it'd be worth keeping the cache as it'd still have a good hit rate, i'm just curious.
562 2017-06-29 20:23:18	0|sipa|cfields: i don't understand
563 2017-06-29 20:23:20	0|gmaxwell|cfields: I'm unclear about what you're asking.
564 2017-06-29 20:24:19	0|cfields|trying to weight the benefits of parallel validation against losing some pre-cached hits
565 2017-06-29 20:24:27	0|sipa|well, do both
566 2017-06-29 20:24:46	0|gmaxwell|yea, there isn't any conflict. You parallel validate the things that miss the cache.
567 2017-06-29 20:24:57	0|sipa|oh, you mean with the block-wide aggregation
568 2017-06-29 20:25:00	0|gmaxwell|do you mean batch validation instead of parallel btw?
569 2017-06-29 20:25:07	0|sipa|my concern there is mostly the layering violation
570 2017-06-29 20:25:14	0|gmaxwell|the block wide aggregation stuff is ugh
571 2017-06-29 20:25:27	0|cfields|yes, sorry. i meant batch.
572 2017-06-29 20:26:22	0|BlueMatt|instagibbs: I think we'd actually see a bigger improvement by responding to getblocktxn requests in the background while connecting a block than making 0.5rtt more common
573 2017-06-29 20:26:30	0|BlueMatt|network-wide that is
574 2017-06-29 20:26:40	0|BlueMatt|though 0.15 may speed up block connection enough.....anyway
575 2017-06-29 20:28:01	0|instagibbs|BlueMatt, i was hoping for lazy improvements, like "it got better" :P
576 2017-06-29 20:28:10	0|instagibbs|yeah I reviewed a PR for that a long while ago
577 2017-06-29 20:29:05	0|sipa|cfields: so for batch validation... batch validate the txn in a block you haven't seen yet, and ignore the rest
578 2017-06-29 20:29:16	0|sipa|(assuming there is no block-wide anything going on)
579 2017-06-29 20:29:39	0|gmaxwell|BlueMatt: if you want to make that even faster: create a ReadBlockFromDisk that returns a blockblob (don't deseralize the transactions in it).
580 2017-06-29 20:29:56	0|gmaxwell|and use that for all getblocky kinds of requests.
581 2017-06-29 20:30:40	0|gmaxwell|(the cases not covered by the cached getblocktxn are whole block requests...)
582 2017-06-29 20:30:52	0|gmaxwell|(and we waste time deseralizing then reserializing the blocks...)
583 2017-06-29 20:31:00	0|cfields|sipa: ah, makes sense
584 2017-06-29 20:31:38	0|gmaxwell|cfields: there is a bit of a conflict right now because batch and parallel are in competition with each other... bigger batches get more speedup, but you want to use all your cores....
585 2017-06-29 20:34:47	0|cfields|is the batch operation itself not parallelizable?
586 2017-06-29 20:34:56	0|BlueMatt|gmaxwell: I'm less concerned about that w/ parallell ProcessMessages - if you ask for an old block its gonna be slow (though I agree that we should fix that, just less interesting for the latency improvements)
587 2017-06-29 20:35:04	0|BlueMatt|instagibbs: well that one got dropped in favor of "doing it cleanly"
588 2017-06-29 20:35:16	0|cfields|i suspect I'm misunderstanding the conflict
589 2017-06-29 20:35:29	0|BlueMatt|instagibbs: now its 10652 + the two other PRs that make up that branch, then an actual parallellization PR
590 2017-06-29 20:35:34	0|BlueMatt|so....16? maybe 17
591 2017-06-29 20:35:39	0|instagibbs|BlueMatt, ah k
592 2017-06-29 20:35:54	0|instagibbs|clearly behind the times
593 2017-06-29 20:38:21	0|sipa|cfields: a batch of 4000 signatures takes less than 8 times as much CPU as a batch of 500 signatures
594 2017-06-29 20:38:47	0|sipa|cfields: if you split the batch up in 8, and run those 8 on separate CPUs, you're going to do 8*batch(500) work, not 1*batch(4000) work
595 2017-06-29 20:39:27	0|gmaxwell|cfields: the algorithim is not naturally parallizable, though with lots of synchronization traffic it can be made parallel.
596 2017-06-29 20:40:01	0|gmaxwell|how much of the batch(4000) speed we can get out of something pushed to be made N-way parallel is an open question.
597 2017-06-29 20:40:13	0|gmaxwell|If synchronization between threads is free the answer is "almost all of it"
598 2017-06-29 20:40:24	0|cfields|ok that's what i was missing, thanks
599 2017-06-29 20:40:28	0|gmaxwell|If it is very expensive, the answer appears to be "almost none of it".
600 2017-06-29 20:40:56	0|cfields|i'll read the paper before discussing further
601 2017-06-29 20:41:08	0|gmaxwell|None of this is in the paper.
602 2017-06-29 20:41:42	0|cfields|oh. in that case, I already read the paper :p
603 2017-06-29 20:41:48	0|sipa|cfields: the 'hard' part of the computation is doing a huge n1*P1 + n2*P2 + n3*P3 + ... (where the n's are integers and the Ps are EC points)
604 2017-06-29 20:42:22	0|sipa|turns out, there is a very neat algorithm (multiple, in fact) that do this whole computation many times faster than just multiplying individually and adding
605 2017-06-29 20:42:57	0|gmaxwell|Same as for a normal signature validation except there it's  just n1 * P + n2 * G  ... so only two ecpoints.  in batch and aggregate validation there is  pubkeys + 1.
606 2017-06-29 20:46:37	0|gmaxwell|done simply, a n1*P requires 256 EC additions (technically 256 doublings and 128 additions, but doublings are about twice as fast as an addition)-- using grade school long multiplication (in base 2).  The batch computation of n1*P1 + n2*P2 + n3*P3 + ... can do the job in about 26 additions per point for 4096 inputs.
607 2017-06-29 20:47:11	0|cfields|whoa
608 2017-06-29 20:47:29	0|cfields|oh, misread :)
609 2017-06-29 20:47:57	0|gmaxwell|yes per point, but still thats almost a 10x speedup over a dumb algorithim.
610 2017-06-29 20:50:25	0|cfields|are there further speedups if the result is known ahead of time and you're just attempting to verify correctness?
611 2017-06-29 20:50:57	0|gmaxwell|What we do in secp256k1 for validation (which is two points) is far from simplisic and takes much less than 256 adds worth of work per each.  I believe it's about equal to about 84 per point.
612 2017-06-29 20:51:20	0|gmaxwell|cfields: the aggregate and batch both count on a property like that.
613 2017-06-29 20:51:41	0|gmaxwell|the R value in the signature is the result of this calculation.
614 2017-06-29 20:52:09	0|cfields|ah, so that's the 32bytes-per-block
615 2017-06-29 20:54:02	0|sipa|cfields: eh, i think you're confused
616 2017-06-29 20:54:08	0|sipa|cfields: perhaps we should move to #secp256k1
617 2017-06-29 20:54:22	0|cfields|sure
618 2017-06-29 20:55:14	0|gmaxwell|To be clear: Batch validation exploits ' the result is known ahead of time and you're just attempting to verify correctness'   --- because the signature (or each signature) has an R value that comes with it, and the signature validation is trying to verify that an R value it computes is the same as the provided one.
619 2017-06-29 20:56:22	0|gmaxwell|You can also encode signatures another way, like the wikipedia article on schnorr signatures does-- using "e,s" which is a hash and a scalar; and this form cannot be batch verified because you don't know the result of that multiexp equation in advance.
620 2017-06-29 21:53:37	0|cfields|BlueMatt: ok, i have the shared_ptr change hacked in, and it's pretty huge. Lots of stuff has to change at the same time... it's kinda hard to avoid a giant commit.
621 2017-06-29 21:54:15	0|cfields|BlueMatt: i have no problem doing your refcount change first, then undoing it with this big change next if you'd prefer.