1 2016-06-02 05:44:30	0|gmaxwell|Our current addnode behavior is more than a little obnoxious.  We won't bring up an addnode if it would leave us with more than the maximum outbound connections, even if none of our existing connections are addnoded.  This means that if your network burps you can end up disconnecting all your addnoded peers, and then fill them back in with random peers.
  2 2016-06-02 05:45:25	0|gmaxwell|Even sitting around manually disconnectnode-ing outbounds that weren't my addnodes took quite a while before it managed to try the addnode before connecting something else.
  3 2016-06-02 05:50:49	0|gmaxwell|I think the behavior should be, we should track if peers are addnodeed.  If we have unconnected addnodes and less han MAX connected addnodes, and less than MAX+1 total connected. ... try adding an addnode.
  4 2016-06-02 05:51:49	0|btcdrak|gmaxwell: I have the same complaint. I just never articulated it.
  5 2016-06-02 05:52:06	0|gmaxwell|I think we introduced this misbehavior around 0.9.x or something.
  6 2016-06-02 05:52:18	0|gmaxwell|a long time ago addnode would just go over the connection limit.
  7 2016-06-02 05:52:56	0|gmaxwell|... and then seperately, every N seconds,  if we have >MAX outbound connections, pick one to evict. (where it would avoid evicting whitelisted and addnode peers, then ones that have recently sent us blocks, then txn, the prefer to keep long uptime).
  8 2016-06-02 05:53:39	0|gmaxwell|The same eviction process could then be used to rotate the outbound connections. (just randomly try to connect to too many, and then let eviction do its thing.)
  9 2016-06-02 06:03:27	0|sipa|gmaxwell: indeed, and we already have eviction code
 10 2016-06-02 06:04:11	0|sipa|just adding a bool to select for incoming or outgoing would be a large part already
 11 2016-06-02 06:08:13	0|gmaxwell|the current eviction code only evicts incoming. I think our strategy for outgoing should be somewhat different... in particular, we have far fewer outgoing.
 12 2016-06-02 06:08:44	0|sipa|for rotation we'd need better logic
 13 2016-06-02 06:08:59	0|sipa|but for preferring addnode over random outgoing maybe not so much
 14 2016-06-02 06:09:14	0|midnightmagic|+1 for addnode prioritization :-)
 15 2016-06-02 06:10:48	0|gmaxwell|yes. I think sort by whitelist/addnode/most-recent-to-send-block/dice would be fine for evicting with the addnode case.
 16 2016-06-02 06:11:40	0|gmaxwell|kinda odd that it would let you partition it by kicking off all your useful peers in favor of some dumb addnodes you plugged in.. but ::shrugs::
 17 2016-06-02 06:17:41	0|sipa|yes, if you had to be whitelisted in order to get an addnode, we could just have addnode bypass the connection limit
 18 2016-06-02 06:18:04	0|sipa|maybe something for post host authentication
 19 2016-06-02 06:20:25	0|gmaxwell|right.
 20 2016-06-02 06:20:28	0|gmaxwell|well baby steps
 21 2016-06-02 06:25:27	0|midnightmagic|.w 2
 22 2016-06-02 06:26:50	0|gmaxwell|sipa: could just be a feature of the p2p auth stuff, once we have that. If mutual auth is successful it bypasses limits.
 23 2016-06-02 06:27:09	0|gmaxwell|(or at least a non-file descriptor related limit)
 24 2016-06-02 06:30:45	0|gmaxwell|sipa: another coner case to consider: say you set 8 addnode peers. They all ban you.
 25 2016-06-02 06:34:30	0|midnightmagic|can I ask for a ptr to where the p2p auth is being worked on?
 26 2016-06-02 06:35:50	0|sipa|midnightmagic: blocked by first having encryption in; see bip 151
 27 2016-06-02 06:37:17	0|midnightmagic|ok
 28 2016-06-02 06:38:12	0|gmaxwell|I guess that banning example suggests having some kind of addnode backoff... and making sure the auto evict runs slow enough after the connect that it won't kick a good peer to make room for a connection that is banned.
 29 2016-06-02 06:43:38	0|midnightmagic|I see a note of the mitm mitigation not being addressed and identity authentication: was this discussed somewhere that I missed?
 30 2016-06-02 06:44:20	0|midnightmagic|(I would be happy with "sometime a few weeks ago in -wizards" or like, I don't mind doing my own legwork but would appreciate a general pointer)
 31 2016-06-02 06:49:17	0|sipa|to address mitm, you need authentication
 32 2016-06-02 06:50:18	0|sipa|jonas started on an authentication bip as well in parallel with bip 151
 33 2016-06-02 06:50:30	0|sipa|but that was postponed to first get encryption done
 34 2016-06-02 06:52:15	0|jonasschnelli|sipa, midnightmagic: there is some stuff from greg: https://people.xiph.org/~greg/auth1.txt
 35 2016-06-02 06:52:32	0|jonasschnelli|Also the auth bip should probably be done before starting with the bip151 implementation
 36 2016-06-02 06:52:54	0|midnightmagic|ok
 37 2016-06-02 07:03:26	0|gmaxwell|I think it's fine to implement before auth is done, so long as whomever is implementing doesn't mind taking some small risk of disruption if changes to the auth design change the encryption.
 38 2016-06-02 07:05:06	0|midnightmagic|gmaxwell: any thought to using proof-of-storage as ephemeral key ratchets? :-)
 39 2016-06-02 07:05:31	0|midnightmagic|er. that was meant generally, not just to gmax. :)
 40 2016-06-02 07:06:29	0|midnightmagic|and, would a group sig in log or constant space be possible for client group-membership proof non-interactively?
 41 2016-06-02 07:10:55	0|gmaxwell|I don't think group sigs fit well in this context, unfortunately.  The server can tell if you are peer X by basically giving you a dummy keyring where all the keys are junk except yours.
 42 2016-06-02 07:11:18	0|gmaxwell|you can't tell that it did this to you if it was successful in deanoning you
 43 2016-06-02 07:11:57	0|gmaxwell|(the log size group sigs also take linear time to sign/verify... we're not actually super bandwidth constrained in this application-- so I think a log sized one doesn't buy us much)
 44 2016-06-02 07:12:13	0|gmaxwell|The constant sized ones use pairing crypto, so then there is a bunch of extra crypto to bring in.
 45 2016-06-02 07:12:48	0|midnightmagic|thank you
 46 2016-06-02 07:14:55	0|gmaxwell|the chaumtoken auth was the best private auth I could come up with so far.
 47 2016-06-02 07:30:16	0|jouke|I'm running a node on ipv4 and onion. I have a lot of peers that have the same "addr" IP, and my addresslocal says: "127.0.0.1". Are those connected trough TOR but are advertising that IP? The subver of those peers are different as well.
 48 2016-06-02 07:35:18	0|gmaxwell|if someone connects into you via onion, their addr will be 127.0.0.1:<something>  and the addrlocal should be your onion address.
 49 2016-06-02 07:35:28	0|gmaxwell|though they can send whatever they want in addrlocal.
 50 2016-06-02 07:38:14	0|jouke|Does the addrlocal in the gepeerinfo field specify on which IP address that node is connected to
 51 2016-06-02 07:38:43	0|gmaxwell|No it is whatever address the remote party claims they think is your address.
 52 2016-06-02 07:38:48	0|jouke|Oh right
 53 2016-06-02 07:39:00	0|jouke|Thanks.
 54 2016-06-02 07:39:50	0|jouke|And the addr field is the address where my nodes comunicates to?
 55 2016-06-02 07:40:07	0|gmaxwell|yes, which is 127.0.0.1 for inbound onion peers.
 56 2016-06-02 07:41:32	0|jouke|I have 57 peers with the same addr IP :-/
 57 2016-06-02 07:42:03	0|gmaxwell|presumably 52.51.something.
 58 2016-06-02 07:42:07	0|jouke|No
 59 2016-06-02 07:42:12	0|jouke|Those I have as well
 60 2016-06-02 07:42:17	0|jouke|On other nodes
 61 2016-06-02 07:42:39	0|jouke|It is is actualy a /32 IP
 62 2016-06-02 07:43:04	0|midnightmagic|that sounds super annoying.
 63 2016-06-02 07:43:11	0|gmaxwell|What do you mean by a "/32 IP"  ... all IPs are /32... because they're hosts not networks. :P
 64 2016-06-02 07:43:33	0|jouke|The bytessent/bytesrecv ratio isn't as skewed as with those 52.51
 65 2016-06-02 07:43:58	0|jouke|gmaxwell: just one and the same IP, not multiple IP's from the same subnet.
 66 2016-06-02 07:44:16	0|gmaxwell|I strongly recommend reporting abusive hosts to their providers, fwiw.
 67 2016-06-02 07:44:56	0|jouke|Hetzner...
 68 2016-06-02 07:44:58	0|midnightmagic|maybe it's a tor exit node or something
 69 2016-06-02 07:45:19	0|gmaxwell|midnightmagic: well thats easily checked. :) (indeed, don't report tor exits)
 70 2016-06-02 07:46:13	0|jouke|It's not in here: https://check.torproject.org/exit-addresses
 71 2016-06-02 07:46:57	0|midnightmagic|Ah. Hetzner. Why am I not surprised. :-/
 72 2016-06-02 07:49:52	0|jouke|I was thinking of having a script that would look at the upload/download ratio and ban nodes with a bad ratio. But wouldn't have worked in this case.
 73 2016-06-02 07:50:58	0|gmaxwell|you can do varrious adhoc things personally, but most don't work broader than that.. too easily avoided. the 52.x sybils could start sending junk traffic... and just waste more of your bandwidth.
 74 2016-06-02 07:51:27	0|gmaxwell|They case no harm except privacy loss, and the solution to that is to fix things so they can't hurt privacy.
 75 2016-06-02 07:52:56	0|gmaxwell|though if they're irritating you, http://0bin.net/paste/EH8fTyfotJSU3Udw#TCHJfA7qDt5odgG+gW4dG9aUEYkJQo6oOTmsuXBAJke  works.
 76 2016-06-02 07:55:06	0|gmaxwell|ah seems that misses 52.51.180.197 and 52.51.204.60
 77 2016-06-02 07:56:38	0|GitHub50|[13bitcoin] 15jonasschnelli opened pull request #8135: [OSX] fix make deploy when compiling on OSX (06master...062016/06/makedeploy) 02https://github.com/bitcoin/bitcoin/pull/8135
 78 2016-06-02 08:06:53	0|jouke|gmaxwell: heh, thanks :)
 79 2016-06-02 08:45:41	0|GitHub104|13bitcoin/06master 142692e1b 15fanquake: [Doc] Simplify OS X build notes...
 80 2016-06-02 08:45:41	0|GitHub104|[13bitcoin] 15jonasschnelli pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/715e9fd7454f...58725ba89dfc
 81 2016-06-02 08:45:42	0|GitHub104|13bitcoin/06master 1458725ba 15Jonas Schnelli: Merge #8029: [Doc] Simplify OS X build notes...
 82 2016-06-02 08:45:45	0|GitHub56|[13bitcoin] 15jonasschnelli closed pull request #8029: [Doc] Simplify OS X build notes (06master...06osx-build-notes) 02https://github.com/bitcoin/bitcoin/pull/8029
 83 2016-06-02 09:11:59	0|GitHub85|13bitcoin/06master 1416698cb 15UdjinM6: PR #7772 is not enough to fix the issue with QCompleter, use event filter instead of `connect`
 84 2016-06-02 09:11:59	0|GitHub85|[13bitcoin] 15jonasschnelli pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/58725ba89dfc...ee1533e262e7
 85 2016-06-02 09:12:00	0|GitHub85|13bitcoin/06master 14ee1533e 15Jonas Schnelli: Merge #8129: Fix RPC console auto completer...
 86 2016-06-02 09:12:09	0|GitHub132|[13bitcoin] 15jonasschnelli closed pull request #8129: Fix RPC console auto completer (06master...06fixRPCAutoCompleter_bitcoin) 02https://github.com/bitcoin/bitcoin/pull/8129
 87 2016-06-02 09:19:53	0|iniana|What can I do to debug the painfully slow sync of my core node on a linux machine? Currently at height 410k and it progresses around 1 block every 3 seconds on average.
 88 2016-06-02 09:27:39	0|jonasschnelli|iniana: what processor? how many RAM? disk stype?
 89 2016-06-02 09:28:04	0|jonasschnelli|1 block every 3 seconds is very likely disk speed or CPU.
 90 2016-06-02 09:28:34	0|jonasschnelli|If you have enough memory, you should try to pass -dbache=4000 (4GB)
 91 2016-06-02 09:28:47	0|jonasschnelli|Even passing -dbcache=2000 can help
 92 2016-06-02 09:28:56	0|jonasschnelli|(default is 300)
 93 2016-06-02 09:33:09	0|iniana|jonasschnelli: blockchain is stored on hdd, dbcache was set to 2000. I have a feeling it is because it is run within a Qubes VM. Is there anyway to measure disk I/O?
 94 2016-06-02 09:34:09	0|jonasschnelli|iniana: I guess you can use iostat on linux
 95 2016-06-02 09:34:41	0|jonasschnelli|iniana: did you enable multicore on your VM? But yes,.. running in a VM can slow down the whole thing.
 96 2016-06-02 09:35:01	0|jonasschnelli|Best fix: don't stress it and wait a couple of days. :)
 97 2016-06-02 09:36:35	0|iniana|jonasschnelli: yes, set to 8 VCPUs, 8GB max memory, 4GB initial memory. Am at height 410k, so should only have to wait a couple of hours :)
 98 2016-06-02 09:36:55	0|jonasschnelli|iniana: yes. What CPU?
 99 2016-06-02 09:37:39	0|jonasschnelli|On my Xeon/SSD I could sync a node in a VirtualBox VM within 3-4h.
100 2016-06-02 09:37:45	0|iniana|core i7, 2yo, not sure on exact specs
101 2016-06-02 09:38:03	0|jonasschnelli|iniana: try run Core with --debug=bench
102 2016-06-02 09:38:22	0|jonasschnelli|You will see if its the disk latency or the ecdsa
103 2016-06-02 09:39:26	0|iniana|I managed to sync a pruned node on a whonix VM (tor-only) a lot faster than what I am experiencing now. Only difference is that was on SSD. But I have used the same HDD before and it was a lot faster then. Some combo of VM and HDD doesn't mix I guess.
104 2016-06-02 09:39:41	0|iniana|Ah great! Will try that debug flag
105 2016-06-02 09:42:06	0|phantomcircuit|iniana, does qubes pass the cpu flags?
106 2016-06-02 09:42:20	0|phantomcircuit|also what version are you running?
107 2016-06-02 09:43:25	0|iniana|phantomcircuit: What are the cpu flags? Am running Qubes 3.1, Core 0.12.1
108 2016-06-02 09:47:32	0|iniana|The following line seems to be the one that takes longest to generate: - Connect 647 transactions: 597.49ms (0.923ms/tx, 0.509ms/txin) [102.29s]
109 2016-06-02 09:48:16	0|iniana|also - Verify 4484 txins: 2407.61ms (0.537ms/txin) [104.76s]
110 2016-06-02 10:01:42	0|wumpus|looks like most time is spent on verification
111 2016-06-02 10:01:50	0|wumpus|how many cores are allocated to that VM?
112 2016-06-02 10:02:36	0|wumpus|bitcoin core makes heavy use of paralellism for verification
113 2016-06-02 10:04:24	0|wumpus|ok 8 VCPUs should be fine
114 2016-06-02 10:05:18	0|sipa|u
115 2016-06-02 10:07:25	0|iniana|Hmm.. There was a sequence of a couple of hundred blocks which were processed very quickly (10/s maybe) after which it resumed with 1 block per 3s again.
116 2016-06-02 10:13:41	0|sipa|are you reindexing or downloading?
117 2016-06-02 10:13:54	0|iniana|downloading
118 2016-06-02 10:14:16	0|sipa|that will explain the speed differences
119 2016-06-02 10:14:31	0|sipa|we download multiple blocks at once
120 2016-06-02 10:14:51	0|sipa|but they don't arrivs in the right order
121 2016-06-02 10:17:20	0|iniana|Are transactions that can't be verified yet during sync added to the mempool or someplace else?
122 2016-06-02 10:17:20	0|sipa|so validation only progresses when the first missing one arrices
123 2016-06-02 10:17:52	0|sipa|you mean transactions in blocks we download? no
124 2016-06-02 10:18:12	0|sipa|the mempool only contains validated transactions
125 2016-06-02 10:18:40	0|iniana|ah ok
126 2016-06-02 10:18:57	0|sipa|say you're synced up to block 10000
127 2016-06-02 10:19:13	0|sipa|and you downloading the 100 blocks that follow
128 2016-06-02 10:19:31	0|sipa|and 10001 though 10099 have arrived
129 2016-06-02 10:19:36	0|sipa|but 10000 has not
130 2016-06-02 10:19:47	0|sipa|then 10000 arrvives
131 2016-06-02 10:20:04	0|sipa|and suddenly you can validate 100 blocks at once
132 2016-06-02 10:25:24	0|iniana|Still weird that it is progressing this slowly though. I mean, it was the same speed when reindexing a previously synced data directory I had copied over. It had all the data and did no downloading. How come there was that sequence of blocks that could be progressed so quickly?
133 2016-06-02 10:27:12	0|iniana|When I restarted bitcoin core recently the verification of the previous 288 blocks was also that slow.
134 2016-06-02 10:29:59	0|sipa|during reindex you also saw some sequence of blocks that wete fast?
135 2016-06-02 10:30:19	0|sipa|not all blocks have the same number of transactions
136 2016-06-02 10:30:43	0|sipa|the initial 288 being slow is due to the cache mot being warmed up
137 2016-06-02 10:31:01	0|sipa|the database entries still have to be loaded from disk
138 2016-06-02 10:31:21	0|iniana|no, during reindex I never saw a fast sequence, though I could have missed it.
139 2016-06-02 10:32:16	0|phantomcircuit|sipa, the p2p block fetching logic needs to be hardened against people being annoying
140 2016-06-02 10:32:25	0|phantomcircuit|there's some very very very slow nodes
141 2016-06-02 10:32:30	0|iniana|Sure, not all blocks are the same size, but from a couple of hundred blocks at height 411k, I bet most of them had a lot of transactions.
142 2016-06-02 10:32:38	0|phantomcircuit|but worse there's some that are ridiculously bursty
143 2016-06-02 10:32:49	0|phantomcircuit|they'll be fast for some blocks and then take 10 seconds to respond to another
144 2016-06-02 11:02:06	0|sipa|iniana: you have high dbcache set in both?
145 2016-06-02 11:03:00	0|iniana|sipa: yes, 2000
146 2016-06-02 11:05:53	0|sipa|whenever the dbcache fills up, it needs tp be written to disk, and afterwards processing is slower for a while
147 2016-06-02 11:06:19	0|sipa|you can see when this happens when the cache size in the UodateTip lines falls back to 0
148 2016-06-02 11:06:34	0|sipa|but that causes sudden slowness, not sudden fastness
149 2016-06-02 11:10:56	0|iniana|Cache currently at 1258MiB, and it is consistently slow.
150 2016-06-02 11:11:15	0|sipa|are you running with debug=bench ?
151 2016-06-02 11:11:21	0|iniana|yes
152 2016-06-02 11:15:00	0|iniana|sipa: Here is a snippet from my log http://pastebin.com/6jWv29uj
153 2016-06-02 11:16:51	0|sipa|all your time is lost on loading database entries
154 2016-06-02 11:17:13	0|sipa|either those are blocks that spend a lot of very old inouts that are not cached
155 2016-06-02 11:17:18	0|sipa|or your disk is very slow
156 2016-06-02 11:17:32	0|sipa|*old inputs
157 2016-06-02 11:20:30	0|iniana|iostat reports 7.8M read and 2.1M write for that particular block deivce. Doesn't feel like it is the bottleneck.
158 2016-06-02 11:22:06	0|sipa|they're all very small reads
159 2016-06-02 11:23:24	0|sipa|what kind of disk?
160 2016-06-02 11:23:31	0|iniana|sipa: ok. I guess this is the performance I have to live with until I upgrade to an SSD?
161 2016-06-02 11:24:14	0|sipa|i have a spinning disk, and numbers are far better than what you're seeing
162 2016-06-02 11:24:22	0|sipa|18s to load all the inputs is crazy
163 2016-06-02 11:24:50	0|iniana|yes, I have used the same disk on a non-virtual machine with much better results.
164 2016-06-02 11:25:05	0|sipa|ah, maybe it's due to the VM setup
165 2016-06-02 11:25:29	0|wumpus|yes VM can make some difference
166 2016-06-02 11:25:50	0|wumpus|there are some curious interactions between fdatasync and VMs for example
167 2016-06-02 11:26:09	0|wumpus|probably because the VM 'disk' is one file in the host OS
168 2016-06-02 11:26:20	0|sipa|wumpus: this is slowness in reads, not writes
169 2016-06-02 11:26:25	0|sipa|so sync is not the issue
170 2016-06-02 11:26:32	0|wumpus|reads shouldn't be affected by VM
171 2016-06-02 11:26:39	0|wumpus|not much, at least
172 2016-06-02 11:27:20	0|wumpus|unless it is some weird compressed image format
173 2016-06-02 11:27:45	0|iniana|I'm using Qubes (xen) if that helps
174 2016-06-02 11:29:08	0|wumpus|what can make a difference in i/o speed is to make sure that you're using a paravirtualized disk, and not e.g. emulating IDE
175 2016-06-02 11:30:01	0|phantomcircuit|iniana, 200+ms to load a block from disk is terrrible
176 2016-06-02 11:32:25	0|iniana|Could be the way I attach the block device to my VM (qvm-block), will explore this further.
177 2016-06-02 11:34:01	0|wumpus|yes qemu allows configuring a lot of things related to emulated devices
178 2016-06-02 11:35:04	0|wumpus|I'd say it is only worth it if you intend to do a lot of syncing, I mean once your node syncs the i/o and CPU usage drops by lots and this all matters very little
179 2016-06-02 11:37:36	0|iniana|wumpus: I guess, but it would be annoying if when I have to turn off the machine only to have to wait for hours until it is synced up again when I turn it on. Plus its fun getting to know how stuff works :)
180 2016-06-02 11:38:35	0|wumpus|sure, as a learning experience it makes sense
181 2016-06-02 11:48:15	0|sipa|iniana: at your sync speed, it takes around 1-2 hours to sync a week of blockchain data
182 2016-06-02 11:48:18	0|sipa|that's terrible
183 2016-06-02 11:48:28	0|sipa|some people sync the whole chain in 4 hours
184 2016-06-02 11:48:47	0|iniana|sipa: yes, its very frustrating
185 2016-06-02 11:48:50	0|sipa|but i don't have any advice but checking your vm disk setup
186 2016-06-02 11:55:28	0|phantomcircuit|iniana, it's xen based
187 2016-06-02 11:57:01	0|iniana|phantomcircuit: yes
188 2016-06-02 11:57:14	0|phantomcircuit|i would say
189 2016-06-02 11:57:20	0|phantomcircuit|"good luck" fixing that issue
190 2016-06-02 11:57:21	0|phantomcircuit|:/
191 2016-06-02 11:57:46	0|iniana|You say I shouldn't waste my time?
192 2016-06-02 11:58:21	0|phantomcircuit|i'd say go ask the qubes people
193 2016-06-02 11:58:33	0|GitHub8|[13bitcoin] 15jonasschnelli opened pull request #8136: Log/report in 10% steps during VerifyDB (06master...062016/06/init_checkblocks) 02https://github.com/bitcoin/bitcoin/pull/8136
194 2016-06-02 12:00:08	0|iniana|How would attaching the disk as a samba or nfs share instead of via xen work out? Has anyone tried loading blockchain data from a remote server that way?
195 2016-06-02 12:03:44	0|sipa|iniana: no, you need mmap support
196 2016-06-02 12:03:54	0|sipa|network filesystems don't offer that
197 2016-06-02 12:04:25	0|phantomcircuit|sipa, do we still require mmap?
198 2016-06-02 12:04:30	0|sipa|leveldb does
199 2016-06-02 12:04:49	0|phantomcircuit|hmm
200 2016-06-02 12:04:59	0|sipa|i think
201 2016-06-02 12:05:07	0|kinlo|isn't requiring mmap a good thing from a performance point of view?
202 2016-06-02 12:05:13	0|sipa|yes
203 2016-06-02 12:05:18	0|phantomcircuit|"meh"
204 2016-06-02 12:05:28	0|sipa|i think you can disable it
205 2016-06-02 12:05:43	0|sipa|i think we may not use mmap on 32-bit
206 2016-06-02 12:07:22	0|wumpus|loading the blockchain data from a network filesystem should work, just not having the database directories there (if it doesn't support mmap)
207 2016-06-02 12:07:51	0|wumpus|I've succesfully used a network block device to store both though
208 2016-06-02 12:08:29	0|wumpus|haven't tried samba nor nfs
209 2016-06-02 12:09:36	0|jonasschnelli|wumpus: is there a startup argument to set the blockfiles directory?
210 2016-06-02 12:09:38	0|wumpus|I've also shared synced node data between windows and linux locally, linux' ntfs implementation surprisingly does work good enough for leveldb
211 2016-06-02 12:10:19	0|jonasschnelli|Or do you need some ln -s?
212 2016-06-02 12:10:21	0|wumpus|no, but you can put stuff all over the place with symbolic linnks
213 2016-06-02 12:10:43	0|jonasschnelli|Right...
214 2016-06-02 12:11:09	0|wumpus|being able to specify different directories as arguments would be mildly useful, although for people that don't know what they're doing it's a foot shooting cannon
215 2016-06-02 12:13:15	0|wumpus|(e.g. we only aquire a lock on the data directory, not on the subdirectories individually, so if you can specify them elsewhere someone may do crazy things like point two bitcoinds at the same place)
216 2016-06-02 12:32:29	0|jonasschnelli|hmm.. travis is strange today:
217 2016-06-02 12:32:30	0|jonasschnelli|W: Failed to fetch https://apt.dockerproject.org/repo/dists/ubuntu-trusty/main/binary-amd64/Packages  Hash Sum mismatch
218 2016-06-02 12:34:24	0|wumpus|scary
219 2016-06-02 12:36:06	0|wumpus|happens every time?
220 2016-06-02 12:43:54	0|sipa|try pressing more buttond
221 2016-06-02 12:46:18	0|wumpus|these are not even our own downloads, but travis pre-installing packages that fails
222 2016-06-02 12:46:37	0|wumpus|so less scary, probably just something with the repository that is misconfigured
223 2016-06-02 12:48:38	0|wumpus|docketprojects's package repository that is, not our repository
224 2016-06-02 13:03:47	0|GitHub10|[13bitcoin] 15pstratem opened pull request #8137: Improve CWallet API with new AccountMove function. (06master...062016-06-02-cwallet-accountmove) 02https://github.com/bitcoin/bitcoin/pull/8137
225 2016-06-02 13:12:01	0|wumpus|pushing more buttons doesn't seem to help
226 2016-06-02 13:58:51	0|MarcoFalke|sipa, but this would cause an include main.h in wallet.h?
227 2016-06-02 13:59:24	0|sipa|MarcoFalke: why in wallet.h?
228 2016-06-02 13:59:36	0|sipa|the constant would just disappear from the .h fr
229 2016-06-02 13:59:52	0|sipa|wallet.cpp would call main to query the current relay fee
230 2016-06-02 14:00:40	0|MarcoFalke|Oh, you mean current relay fee and not minimum relay fee.
231 2016-06-02 14:01:04	0|sipa|even the minimum relay fee is configurable, so indeed :)
232 2016-06-02 14:01:27	0|sipa|or even the minimum confirmable feerate
233 2016-06-02 14:01:40	0|sipa|as we should never create outputs that are uneconomical to spend
234 2016-06-02 14:01:51	0|sipa|and the fee estimate is the best guess for that
235 2016-06-02 14:10:10	0|phantomcircuit|sipa, im seeing pull tester failures on master
236 2016-06-02 14:10:22	0|phantomcircuit|can you (or someone else) check?
237 2016-06-02 14:10:25	0|phantomcircuit|wumpus, ^
238 2016-06-02 14:11:02	0|wumpus|still the apt-get issue?
239 2016-06-02 14:11:06	0|wumpus|nothing we can do there
240 2016-06-02 14:12:07	0|wumpus|docker needs to wake up on this https://github.com/docker/docker/issues/23203
241 2016-06-02 14:13:10	0|sipa|MarcoFalke: also, unrelated... i don't think we should care much about header file dependencies (apart from making compilation time and memory larger, they don't hurt modularity)... what matters is dependencies between (.h,.c) pairs on eachother, and wallet.cpp already depends on main.cpp
242 2016-06-02 14:13:16	0|phantomcircuit|wumpus, no im testing locally
243 2016-06-02 14:13:49	0|MarcoFalke|ok
244 2016-06-02 14:14:38	0|sipa|the reasoning being: you already can't use the functionality from wallet.{cpp,h} without having main.{cpp,h} available, so there already is a dependency
245 2016-06-02 14:22:31	0|jonasschnelli|MarcoFalke: sipa: what about introducing a nodemodel.{cpp/h} that could act as a wallet/node API?
246 2016-06-02 14:22:52	0|sipa|how is that different from clientmodel?
247 2016-06-02 14:23:00	0|jonasschnelli|clientmodel is GUI
248 2016-06-02 14:23:06	0|jonasschnelli|nodemodel would be core/wallet
249 2016-06-02 14:23:12	0|sipa|i don't understand
250 2016-06-02 14:23:28	0|sipa|clientmodel is the abstraction of the client/node that the GUI uses to communicate with core
251 2016-06-02 14:23:31	0|jonasschnelli|Main reason for this could be to have all node interaction in a single file (better readability, better source for later decoupling)
252 2016-06-02 14:23:48	0|jonasschnelli|Yes. It could also be clientmodel...
253 2016-06-02 14:23:49	0|sipa|ah, you mean a lower level
254 2016-06-02 14:23:52	0|jonasschnelli|yes.
255 2016-06-02 14:24:04	0|sipa|what sort of code would move there?
256 2016-06-02 14:24:14	0|jonasschnelli|Fee estimation, relay fee, etc.
257 2016-06-02 14:24:19	0|jonasschnelli|broadcast
258 2016-06-02 14:25:36	0|sipa|i wouldn't put wallet-related things there (as those shouldn't be lumped together long term)
259 2016-06-02 14:26:01	0|sipa|but if there are pieces of code shared between gui and rpc, it makes sense to move them to a common abstraction layer below
260 2016-06-02 14:28:59	0|wumpus|wallet.cpp can depend on main.cpp, but not the other way around
261 2016-06-02 14:30:39	0|wumpus|I'm not sure adding all node interaction in a single file is a step forward; we'tre trying to modularize things beyond that, e.g. net is different from blockchain handling
262 2016-06-02 14:31:42	0|jonasschnelli|Yes. I agree, move it to a single file would only increase code readability, ... and not sure if this is worth a PR.
263 2016-06-02 14:32:48	0|sipa|wumpus: agree
264 2016-06-02 14:33:33	0|sipa|i think we're perhaps better off spending time to move code from RPC calls (especially the complicated code inside RPCs that grabs cs_main) to somewhere in the core code instead, so that the RPC is just a single call
265 2016-06-02 14:33:34	0|wumpus|clientmodel has way too many responsibilities
266 2016-06-02 14:34:00	0|wumpus|(but it's fine for the GUI, and was a big step forward from satoshi's stuff)
267 2016-06-02 14:34:41	0|wumpus|yes, that makes sense, ideally only main functions would lock cs_main
268 2016-06-02 14:34:49	0|wumpus|on the other hand at this point I'd not like moving things into main
269 2016-06-02 14:34:58	0|wumpus|main has the same issue
270 2016-06-02 14:35:03	0|wumpus|but after net refactors etc, sure
271 2016-06-02 14:36:44	0|wumpus|I don't think RPC functions necessarily need to be just a single call, what matters is that operations that need to happen under cs_main lock and act on main data structures would be better off in main, but these could be the minimal possible encapsulated operations
272 2016-06-02 14:36:54	0|sipa|wumpus: +1
273 2016-06-02 14:37:18	0|sipa|anything that grabs a lock should be moved to the module that manages that lock
274 2016-06-02 14:37:39	0|sipa|(in practice, that often means introducing callback functions etc... though)
275 2016-06-02 14:37:50	0|wumpus|aren't we happy with c++11 lambdas then
276 2016-06-02 14:38:08	0|sipa|i should learn to use those :)
277 2016-06-02 14:38:11	0|sipa|but yes
278 2016-06-02 14:38:39	0|wumpus|cfields taught me how to use them in Zurich
279 2016-06-02 14:39:11	0|wumpus|I'm impressed, the functionality is so flexible it seems almost un-c++
280 2016-06-02 14:40:42	0|wumpus|(e.g. how code in a lambda can use variables from the enclosing function is more remniscent of dynamic languages)
281 2016-06-02 14:41:22	0|wumpus|phantomcircuit: if you run it locally you should have an error message?
282 2016-06-02 14:41:33	0|gmaxwell|GCC nested functions can do that too.
283 2016-06-02 14:44:08	0|phantomcircuit|wumpus, i have lots of error messages
284 2016-06-02 14:44:14	0|wumpus|didn't know that! there's not really precedent, c++ nested classes cannot access members from enclosing classes, like in java static inner classes
285 2016-06-02 14:44:21	0|phantomcircuit|im checking again after a git clean -fdx
286 2016-06-02 14:44:31	0|wumpus|phantomcircuit: so the autotests fails?
287 2016-06-02 14:44:48	0|wumpus|or the qa tests?
288 2016-06-02 14:44:49	0|phantomcircuit|wumpus, rpc pull tests fail
289 2016-06-02 14:44:55	0|phantomcircuit|make check tests pass
290 2016-06-02 14:45:19	0|MarcoFalke|which rpc-test?
291 2016-06-02 14:45:29	0|phantomcircuit|a bunch of the wallet related ones
292 2016-06-02 14:45:41	0|phantomcircuit|i'll clarify in a minute when im done recompiling
293 2016-06-02 14:54:08	0|phantomcircuit|and now everything passes
294 2016-06-02 14:54:09	0|phantomcircuit|>.>
295 2016-06-02 14:54:11	0|phantomcircuit|nvm
296 2016-06-02 15:01:05	0|GitHub38|[13bitcoin] 15jonasschnelli opened pull request #8138: Add maximal amount-of-transactions limit to checkblock/CVerifyDB (06master...062016/06/verify_db) 02https://github.com/bitcoin/bitcoin/pull/8138
297 2016-06-02 15:19:13	0|sipa|ping for review: https://github.com/bitcoin/bitcoin/pull/7948 (RPC: augment getblockchaininfo bip9_softforks data)
298 2016-06-02 15:20:04	0|sipa|ping for review: https://github.com/bitcoin/bitcoin/pull/7967 ([RPC] add feerate option to fundrawtransaction)
299 2016-06-02 15:56:17	0|sipa|phantomcircuit: are you seeing this:
300 2016-06-02 15:56:26	0|sipa|https://www.zerobin.net/?340fa0188dd35804#2Hkj8AQ8nQtI3LWQpGNrAHGnmRVeCiqVvm9BkG2+HpM=
301 2016-06-02 16:00:53	0|sipa|MarcoFalke: ^
302 2016-06-02 16:04:22	0|MarcoFalke|sipa: any zombie bitcoinds? ps -A |grep bitcoind
303 2016-06-02 16:04:28	0|sipa|nope
304 2016-06-02 16:04:40	0|MarcoFalke|reproducible?
305 2016-06-02 16:04:48	0|sipa|retried the test walletbackup.py itself and got a different error
306 2016-06-02 16:05:06	0|sipa|now trying rpc-tests.py again, and it seems to run ok
307 2016-06-02 16:05:20	0|sipa|at least it doesn't instantly fail like before
308 2016-06-02 16:05:51	0|MarcoFalke|Have you been running ./rpc-tests.py in parallel?
309 2016-06-02 16:06:06	0|MarcoFalke|(This doesn't work)
310 2016-06-02 16:06:13	0|sipa|no
311 2016-06-02 16:06:28	0|sipa|if you mean multiple instances of rpc-tests.py simultaneously, no
312 2016-06-02 16:06:32	0|MarcoFalke|jup
313 2016-06-02 17:14:57	0|GitHub121|[13bitcoin] 15sipa pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/ee1533e262e7...ec45cc5e2766
314 2016-06-02 17:14:58	0|GitHub121|13bitcoin/06master 146030625 15Wladimir J. van der Laan: test: Add more thorough test for dbwrapper iterators...
315 2016-06-02 17:14:58	0|GitHub121|13bitcoin/06master 1484c13e7 15Wladimir J. van der Laan: chain: Add assertion in case of missing records in index db
316 2016-06-02 17:14:59	0|GitHub121|13bitcoin/06master 14269a440 15Matt Corallo: Add test for dbwrapper iterators with same-prefix keys.
317 2016-06-02 17:15:02	0|GitHub78|[13bitcoin] 15sipa closed pull request #7992: Extend #7956 with one more test. (06master...0616-5-7956-update) 02https://github.com/bitcoin/bitcoin/pull/7992
318 2016-06-02 17:15:14	0|GitHub30|[13bitcoin] 15sipa closed pull request #8051: Seemingly fix walletbackup.py failure (06master...06fixwalletbackup) 02https://github.com/bitcoin/bitcoin/pull/8051
319 2016-06-02 17:17:35	0|GitHub20|[13bitcoin] 15sipa opened pull request #8139: Fix interrupted HTTP RPC connection workaround for Python 3.5+ (06master...06fixwalletbackup) 02https://github.com/bitcoin/bitcoin/pull/8139
320 2016-06-02 18:55:46	0|GitHub100|[13bitcoin] 15mrbandrews opened pull request #8141: Continuing port of java comparison tool (06master...06ba-comptool) 02https://github.com/bitcoin/bitcoin/pull/8141
321 2016-06-02 18:58:52	0|BakSAj|hi
322 2016-06-02 18:59:17	0|wumpus|hi
323 2016-06-02 18:59:55	0|BakSAj|bitcoin core live meeting now?
324 2016-06-02 18:59:59	0|wumpus|yes
325 2016-06-02 19:00:05	0|BakSAj|good :-)
326 2016-06-02 19:00:10	0|sipa|yes
327 2016-06-02 19:00:13	0|BakSAj|any outlook on merging segwit to master?
328 2016-06-02 19:00:24	0|lightningbot|Meeting started Thu Jun  2 19:00:23 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
329 2016-06-02 19:00:24	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
330 2016-06-02 19:00:24	0|wumpus|#startmeeting
331 2016-06-02 19:00:36	0|luke-jr|aww, too fast
332 2016-06-02 19:00:59	0|luke-jr|I was going to propose a topic very unseriously explicitly outside the meeting. :P now it's time to be serious
333 2016-06-02 19:01:09	0|petertodd|hi
334 2016-06-02 19:01:34	0|gmaxwell|jtimon: Cory: morcos: sdaftuar: btcdrak: phantomcircuit: jonasschnelli:
335 2016-06-02 19:01:34	0|wumpus|I guess segwit is the recurring topic, any other topic proposals?
336 2016-06-02 19:01:42	0|jonasschnelli|Here!
337 2016-06-02 19:01:47	0|sipa|cfields_!
338 2016-06-02 19:02:02	0|gmaxwell|I can give some updates on compactblock testing, since it seems that Matt isn't around (or if he shows up, I expect he can)
339 2016-06-02 19:02:42	0|wumpus|great
340 2016-06-02 19:03:18	0|wumpus|#topic segwit review
341 2016-06-02 19:03:50	0|wumpus|let's start with that then
342 2016-06-02 19:04:02	0|sipa|My plan right now is making the BIP9/GBT changes, removing segnet, removing the positive witness flag, and then creating a parallel rebase
343 2016-06-02 19:04:12	0|sipa|with has a clean history but leads to the same tree
344 2016-06-02 19:04:19	0|sipa|if that is something wanted at this point
345 2016-06-02 19:04:21	0|wumpus|111 comments on PR #7910, that must be a record
346 2016-06-02 19:04:32	0|luke-jr|"positive witness flag"?
347 2016-06-02 19:05:27	0|sipa|luke-jr: originally, there was a flag to the serialize code to say "serialize witnesses!"; at some point we realized that the opposite was better, as almost always you want to serialize witnesses, and there are just a few exceptions
348 2016-06-02 19:05:48	0|sipa|so i introduced both temporarily, and required that exactly one of both was set
349 2016-06-02 19:05:51	0|luke-jr|oh, I thought having it explicit was a good idea
350 2016-06-02 19:06:23	0|sipa|luke-jr: one reason for the opposite is that a failure where you miss the positive flag will not be detected usually, but failure to set a negative flag will
351 2016-06-02 19:06:30	0|sipa|luke-jr: i thought the same thing initially
352 2016-06-02 19:06:59	0|instagibbs|sipa, are you removing new wallet functionality as well?
353 2016-06-02 19:07:07	0|sipa|instagibbs: ?
354 2016-06-02 19:07:10	0|luke-jr|sipa: what downsides are there to the current explicit flag?
355 2016-06-02 19:07:25	0|sipa|21:06:22 < sipa> luke-jr: one reason for the opposite is that a failure where you miss the positive flag will not be detected usually, but failure to set a negative flag will
356 2016-06-02 19:07:37	0|instagibbs|I assume you don't want users to have segwit addresses pre-rollout
357 2016-06-02 19:07:41	0|petertodd|luke-jr: indeed, I might have very well written it with a separate CWitnessTx class :)
358 2016-06-02 19:07:53	0|luke-jr|sipa: I don't understand that answer. :<
359 2016-06-02 19:07:55	0|instagibbs|(unless that would still be a testing branch)
360 2016-06-02 19:08:31	0|sipa|luke-jr: if we use a positive flag only, and we miss setting that flag somewhere, it won't easily be detected, as wherever that data goes, it will likely also accept tx without witness
361 2016-06-02 19:08:46	0|luke-jr|right, I'm talking about where we have both positive and negative flags..
362 2016-06-02 19:08:51	0|sipa|ah, that is also an option
363 2016-06-02 19:09:05	0|sipa|it's just more code changes shattered all over the place
364 2016-06-02 19:09:44	0|luke-jr|less likely to have it accidentally wrong, though
365 2016-06-02 19:09:50	0|gmaxwell|With segwit in place there really isn't much further concern about getting the wrong flags, it should only have been an issue with the migration where support had to be added in many places (like RPCs) that might have less test coverage.
366 2016-06-02 19:10:11	0|gmaxwell|If you get it wrong in the future, the thing you changed simply won't work right. And hopefully you'll be testing the thing you just changed.
367 2016-06-02 19:10:20	0|gmaxwell|I don't have a strong or strongly held opinion however.
368 2016-06-02 19:10:50	0|luke-jr|we have a lot of outstanding PRs that may need to be updated that might not conflict
369 2016-06-02 19:10:51	0|jtimon|ack on cleaning history while removing the testnet
370 2016-06-02 19:11:02	0|wumpus|instagibbs: well in principle, master is attesting branch
371 2016-06-02 19:11:35	0|sipa|there are a few things we need in first, though
372 2016-06-02 19:11:38	0|petertodd|jtimon: you mean segnet?
373 2016-06-02 19:11:39	0|wumpus|jtimon: you mean removing the segnet? don't make him remove testnet too :)
374 2016-06-02 19:11:44	0|instagibbs|oh a testing, not attesting
375 2016-06-02 19:12:04	0|jtimon|petertodd: I believe sipa meant removing segwit's testnet
376 2016-06-02 19:12:13	0|gmaxwell|sipa: in any case, what do you think will let you get the code merged sooner?
377 2016-06-02 19:12:14	0|sipa|#7749 and #8083
378 2016-06-02 19:12:27	0|wumpus|but yes ACK on cleaning up the history before merge
379 2016-06-02 19:12:37	0|gmaxwell|I like cleaning history for sure.
380 2016-06-02 19:12:44	0|gmaxwell|Future me thanks you.
381 2016-06-02 19:13:03	0|sipa|well it definitely has to happen before merge
382 2016-06-02 19:13:06	0|jonasschnelli|As said, we can ACK the sha256sum of the diff (if someone cares about integrity of an ACK)
383 2016-06-02 19:13:08	0|sipa|the question whether the time is now for that
384 2016-06-02 19:13:18	0|luke-jr|(GBT VB as well)
385 2016-06-02 19:13:21	0|sipa|jonasschnelli: git internally has tree hashes
386 2016-06-02 19:13:35	0|jonasschnelli|sipa: Nice. That should work.
387 2016-06-02 19:14:13	0|sipa|So please review #7749 and #8083
388 2016-06-02 19:14:26	0|luke-jr|did we get anywhere with the fundrawtransaction issue?
389 2016-06-02 19:14:41	0|sipa|luke-jr: i can't remember the conclusion there
390 2016-06-02 19:14:49	0|jonasschnelli|Re 8083: im finalizing the seeder part (nits and filterbitmap-whitelist)
391 2016-06-02 19:14:49	0|wumpus|q: is everything in the segwit PR meant to go in at once, or will it be split up in to, say, a pull with consensus/network changes, following up with wallet, and GUI changes
392 2016-06-02 19:15:03	0|wumpus|#action review #7749 and #8083
393 2016-06-02 19:15:08	0|luke-jr|sipa: IIRC, 1) it's a problem; 2) we won't change consensus code to fix it
394 2016-06-02 19:15:26	0|luke-jr|I don't know of any actual resolution to the problem :/
395 2016-06-02 19:15:41	0|gmaxwell|wumpus: If sipa does the "rewrite history to result in the same code thing" then if it is is PR split they will need to go in one right after another to preserve the "same code" property.
396 2016-06-02 19:15:56	0|gmaxwell|(I think)
397 2016-06-02 19:16:02	0|sipa|wumpus: that's a good question; the history is broken into sections already
398 2016-06-02 19:16:07	0|sipa|so we can decide later
399 2016-06-02 19:16:21	0|sipa|though... maybe not
400 2016-06-02 19:16:27	0|gmaxwell|I suppose sipa should show "same code" at one point, then split, and the remaining parts could then change.
401 2016-06-02 19:16:38	0|sipa|the unit/rpc/p2p tests rely on the wallet code
402 2016-06-02 19:16:39	0|wumpus|gmaxwell: I don't have a strong opinion either way, if this change is sufficiently atomic it makes sense to do it at once, but see e.g. instagibbs's comment about wallet addresses
403 2016-06-02 19:17:12	0|wumpus|maybe hide it behind an option in the beginning?
404 2016-06-02 19:17:24	0|gmaxwell|My recommendation for the wallet parts was to just hide the changed functionality there behind a hidden configuration option that the tests could use.
405 2016-06-02 19:17:29	0|jtimon|well, the wallet code can be maybe be introduced disabled for users with a constant to be removed later or something?
406 2016-06-02 19:17:30	0|sipa|maybe we can disable addwitnessaddress before the softfork
407 2016-06-02 19:17:33	0|wumpus|gmaxwell: right
408 2016-06-02 19:17:38	0|sipa|that would make sense
409 2016-06-02 19:17:47	0|wumpus|jtimon: hey we're all saying the same :)
410 2016-06-02 19:17:52	0|jtimon|wumpus: yes
411 2016-06-02 19:17:52	0|sipa|yay, agreement
412 2016-06-02 19:17:57	0|sipa|i have another question
413 2016-06-02 19:18:03	0|gmaxwell|sipa: what is the meaning of life?
414 2016-06-02 19:18:06	0|sipa|42
415 2016-06-02 19:18:07	0|jonasschnelli|:)
416 2016-06-02 19:18:14	0|gmaxwell|thats an answer, not a question!
417 2016-06-02 19:18:33	0|luke-jr|he has both the answer and a question
418 2016-06-02 19:18:35	0|gmaxwell|We're going to need to build a bigger computer...
419 2016-06-02 19:18:36	0|sipa|jl2012 brought up the issue that our witness program definition is limited to 16 versions, and that is not easy to extend without introducing a new witness storage
420 2016-06-02 19:18:57	0|sipa|there is an easy solution, by allowing witness programs to be slightly larger
421 2016-06-02 19:19:01	0|sipa|but this is a hard forking change
422 2016-06-02 19:19:12	0|luke-jr|sipa: it is? I thought the version could be any length?
423 2016-06-02 19:19:14	0|sipa|which, if done unconditionally, could hardfork testnet
424 2016-06-02 19:19:22	0|sipa|luke-jr: nope, has to be OP_0 through OP_16
425 2016-06-02 19:19:27	0|luke-jr|:/
426 2016-06-02 19:19:33	0|luke-jr|why limit it?
427 2016-06-02 19:19:42	0|jtimon|then would be something to move to the later hardfork, no?
428 2016-06-02 19:20:01	0|sipa|jtimon: i don't like relying on that
429 2016-06-02 19:20:08	0|gmaxwell|Oh ... how'd that happen? in any case, you can simply use 0..16 and then use another byte after that one.
430 2016-06-02 19:20:16	0|luke-jr|jtimon: we cannot assume there will ever be a hardfork.
431 2016-06-02 19:20:18	0|sipa|gmaxwell: max 32 bytes can follow
432 2016-06-02 19:20:31	0|gmaxwell|okay thats broken.
433 2016-06-02 19:20:45	0|jtimon|well, the plan was to deploy segwit as a softfork
434 2016-06-02 19:21:08	0|gmaxwell|My assumption was that it would be arbritary and extended by just adding more bytes when the space ran out.
435 2016-06-02 19:21:08	0|sipa|jtimon: changing it is a HF with respect to the current SW code
436 2016-06-02 19:21:14	0|sipa|jtimon: not with respect to bitcoin
437 2016-06-02 19:21:35	0|sipa|jtimon: so we can change it before merge while leaving SW a SF
438 2016-06-02 19:21:36	0|jtimon|sipa: oh, I see, it would still be a SF to bitcoin. ok
439 2016-06-02 19:21:55	0|sipa|gmaxwell, luke-jr: the reason was that constant size utxos are nice
440 2016-06-02 19:21:56	0|gmaxwell|sipa: testnet segwit rules can be changed so activiation doesn't begin until later.
441 2016-06-02 19:22:06	0|gmaxwell|So at worst that would be a reindex for testnet nodes, no?
442 2016-06-02 19:22:12	0|sipa|gmaxwell: ... segwit is already activated on testnet
443 2016-06-02 19:22:16	0|gmaxwell|yes, so?
444 2016-06-02 19:22:16	0|luke-jr|sipa: they're already non-constant size.
445 2016-06-02 19:22:22	0|sipa|luke-jr: ?
446 2016-06-02 19:22:24	0|gmaxwell|sipa: move it forward, reindex.
447 2016-06-02 19:22:25	0|jtimon|testnet4 ?
448 2016-06-02 19:22:27	0|gmaxwell|luke-jr: he means in the future.
449 2016-06-02 19:22:37	0|gmaxwell|sipa: in any case, 16 is unacceptably too few.
450 2016-06-02 19:22:41	0|sipa|agree
451 2016-06-02 19:23:26	0|sipa|gmaxwell: hmm, ok
452 2016-06-02 19:23:31	0|instagibbs|The bip doesn't read like it would be a HF, but maybe I'm being obtuse
453 2016-06-02 19:23:38	0|gmaxwell|I don't think constant size is as interesting as constant bound. so if you wanted to say that the version was limited to N bytes for some small N that would be fine. 4294967296 versions should be enough for anyone.
454 2016-06-02 19:23:39	0|luke-jr|gmaxwell: in the future, if we softfork out the current long sPKs, we can softfork a limit on witness sPK length as well
455 2016-06-02 19:23:58	0|sipa|fair enough, will do
456 2016-06-02 19:24:09	0|sipa|limit to 36 or 40 bytes or so
457 2016-06-02 19:24:10	0|jtimon|instagibbs: it would be a HF only for testnet3 which has already deployed "old segwit"
458 2016-06-02 19:24:32	0|instagibbs|jtimon, no I mean, anything where version is 1+ has no consensus meaning yet
459 2016-06-02 19:24:39	0|gmaxwell|sipa: cool (also, testnet behavior has never been in a merged much less released version, I don't mind breaking it)
460 2016-06-02 19:24:41	0|instagibbs|when it's not simply 0
461 2016-06-02 19:25:16	0|sipa|instagibbs: the problem is that something of the form "1 + 33 bytes" is not treated as a witness program, and is not allowed to have any witness data
462 2016-06-02 19:25:32	0|sipa|we can extend the definition of a witness program, but it would require a new witness structure
463 2016-06-02 19:25:49	0|sipa|as old nodes won't relay witness data with something they don't treat as a witness output
464 2016-06-02 19:25:59	0|sipa|(and that rule is necessary to prevent spam)
465 2016-06-02 19:26:27	0|sipa|anyway, ok, will just change the rule
466 2016-06-02 19:26:37	0|sipa|other topics?
467 2016-06-02 19:26:43	0|wumpus|yes
468 2016-06-02 19:26:46	0|luke-jr|old nodes won't relay anything with witness data they can't verify anyway..
469 2016-06-02 19:26:49	0|sipa|(or more segwit review related points)
470 2016-06-02 19:26:56	0|wumpus|#topic compactblock testing
471 2016-06-02 19:27:01	0|sipa|luke-jr: old nodes in this case being witness v0 nodes
472 2016-06-02 19:27:05	0|instagibbs|luke-jr, I'm not convinced, but I think fixing now is better anyways so whatever
473 2016-06-02 19:27:07	0|luke-jr|sipa: yes, I also mean these
474 2016-06-02 19:27:11	0|wumpus|@gmaxwell
475 2016-06-02 19:27:14	0|luke-jr|IMO make any length limit a relay policy only.
476 2016-06-02 19:27:22	0|sipa|we'll discuss further in #segwit-dev
477 2016-06-02 19:27:24	0|luke-jr|k
478 2016-06-02 19:27:28	0|instagibbs|ack
479 2016-06-02 19:28:01	0|jtimon|compackblock
480 2016-06-02 19:28:24	0|gmaxwell|Okay. So matt has built a parallel relay network that uses compact blocks and the UDP network block coding stuff.
481 2016-06-02 19:28:24	0|sipa|i rebased BlueMatt's compactblock patch on top of the shared_ptr mempool change, and gmaxwell and i have been succesfully running it across the internet
482 2016-06-02 19:28:38	0|sipa|^ and that's more interesting
483 2016-06-02 19:28:54	0|gmaxwell|^ a number of people-- including some large miners-- are running both Sipa's rebase,  and Matt's PR without the rebase on public nodes.
484 2016-06-02 19:29:16	0|gmaxwell|Which are also connecting to matt's nodes.
485 2016-06-02 19:29:32	0|wumpus|good to hear
486 2016-06-02 19:29:33	0|gmaxwell|(I got bored with the simulated topology lab testing, this is potentially more interesting)
487 2016-06-02 19:29:40	0|sipa|2016-06-02 18:36:13.412286 Successfully reconstructed block 0000000000000000014a6a924544dd097d538314281bebd95c89e50726e7d2ef with 1 txn prefilled, 2708 txn from mempool and 0 txn requested
488 2016-06-02 19:29:44	0|sipa|2016-06-02 18:37:46.728092 Successfully reconstructed block 000000000000000001943282946e9579fd84def95df577ebb8bcda3b8d9f4d06 with 1 txn prefilled, 1529 txn from mempool and 0 txn requested
489 2016-06-02 19:29:48	0|sipa|2016-06-02 18:43:32.713909 Successfully reconstructed block 000000000000000000499e1485726cd87003e7a6400118f8c061171748665612 with 1 txn prefilled, 1102 txn from mempool and 3 txn requested
490 2016-06-02 19:29:53	0|wumpus|yes, always good to test with real world data as well
491 2016-06-02 19:30:04	0|gmaxwell|I don't know that there is much to report, it's working as expected.  :)   Sipa's rebase on the sharedptr is pretty nice.
492 2016-06-02 19:30:23	0|instagibbs|gmaxwell, the rebase includes the predicted transactions?
493 2016-06-02 19:30:30	0|BakSAj|nice
494 2016-06-02 19:30:31	0|gmaxwell|As it also eliminates transaction duplication from the relay pool, and eliminates a fair bit of transaction copying.
495 2016-06-02 19:30:32	0|wumpus|is this branch available somewhere?
496 2016-06-02 19:30:34	0|sipa|instagibbs: it only sends the coinbase directly
497 2016-06-02 19:30:39	0|instagibbs|sipa, ah k
498 2016-06-02 19:30:52	0|gmaxwell|instagibbs: no, right now I don't believe anyone is running something with fancy prediction.  I think we'll leave that out in the initial PR. Easily added later.
499 2016-06-02 19:30:53	0|sipa|wumpus: https://github.com/sipa/bitcoin/commits/compactblocks
500 2016-06-02 19:31:39	0|wumpus|#link sipa's rebase of compactblocks on top of PR #8126: https://github.com/sipa/bitcoin/commits/compactblocks
501 2016-06-02 19:31:55	0|wumpus|#action review PR #8126
502 2016-06-02 19:32:01	0|gmaxwell|if other developers here are interested in running nodes connected to these nodes, lemme know and I'll give you addresses to connect to.
503 2016-06-02 19:32:17	0|wumpus|I'm interested
504 2016-06-02 19:32:28	0|gmaxwell|I should take an action to setup a couple on published addresses too, for people to connect to without asking. :)
505 2016-06-02 19:33:00	0|wumpus|yes, that always works best :)
506 2016-06-02 19:33:16	0|wumpus|any other topics?
507 2016-06-02 19:33:19	0|luke-jr|is sipa's rebase different enough that we ought to switch to reviewing that instead?
508 2016-06-02 19:33:20	0|gmaxwell|Yes, though they may get DDOS attacked, which is harmless but would waste time sorting out the issue. :)
509 2016-06-02 19:33:42	0|sipa|luke-jr: it's less code than the original :)
510 2016-06-02 19:33:55	0|wumpus|gmaxwell: you mean thoroughly stress-tested :)
511 2016-06-02 19:34:17	0|gmaxwell|Does anyone know the current CFPF status?
512 2016-06-02 19:34:34	0|wumpus|#topic current CPFP status
513 2016-06-02 19:34:43	0|sipa|gmaxwell: review #7598
514 2016-06-02 19:34:52	0|luke-jr|afaik no show-stoppers found, but more review needed; there's a dep PR to get in first though
515 2016-06-02 19:34:52	0|wumpus|#action  review #7598
516 2016-06-02 19:35:09	0|sipa|it's a blocker/dependency for CPFP (#7600)
517 2016-06-02 19:37:34	0|gmaxwell|I've been struggling a bit with too many PRs outstanding at once that I want to test.
518 2016-06-02 19:37:36	0|wumpus|#link CPFP is that like 'strong AI should be here in less than 20 years'
519 2016-06-02 19:37:42	0|wumpus|EH
520 2016-06-02 19:37:47	0|luke-jr|:<
521 2016-06-02 19:37:49	0|wumpus|#link https://github.com/bitcoin/bitcoin/pull/7600
522 2016-06-02 19:38:01	0|wumpus|(sorry, copy paste messup)
523 2016-06-02 19:38:04	0|gmaxwell|Merging them is a pain.  (thanks to sipa for merging a lot of things recently!)
524 2016-06-02 19:38:48	0|sipa|i've been going through all PRs... there are so many decent-but-not-quite-finished ones in the queue...
525 2016-06-02 19:38:50	0|wumpus|I've lost overview a bit
526 2016-06-02 19:38:59	0|wumpus|any PRs that should be close to be able to be merged?
527 2016-06-02 19:39:17	0|wumpus|sipa: yes, I've noticed
528 2016-06-02 19:39:22	0|jonasschnelli|IMO https://github.com/bitcoin/bitcoin/pull/7957 can be merged (save, tool only)
529 2016-06-02 19:39:30	0|gmaxwell|Mostly my minor difficulty there just comes from many things touching the same parts, and a lot of that was actually my fault. (e.g. opening three PRs at once that all conflicted with each other. :) )
530 2016-06-02 19:39:52	0|luke-jr|I'd like to see key generation type merged so there's no risk of other wallet upgrades conflicting it since these wallets are in the wild
531 2016-06-02 19:39:57	0|sipa|17:19:13 < sipa> ping for review: https://github.com/bitcoin/bitcoin/pull/7948 (RPC: augment getblockchaininfo bip9_softforks data)
532 2016-06-02 19:40:00	0|sipa|17:20:03 < sipa> ping for review: https://github.com/bitcoin/bitcoin/pull/7967 ([RPC] add feerate option to fundrawtransaction)
533 2016-06-02 19:40:23	0|wumpus|jonasschnelli: agree, but that one is probably not blocking anything
534 2016-06-02 19:40:38	0|sipa|also 7997
535 2016-06-02 19:41:07	0|jonasschnelli|I'm requesting permission to merge [docs] and [tools] PRs
536 2016-06-02 19:41:21	0|wumpus|jonasschnelli: sure
537 2016-06-02 19:42:09	0|gmaxwell|sounds fine, I know we sometimes don't get enough review on those, esp docs. Please feel empowered to nag people to review things.
538 2016-06-02 19:42:11	0|jonasschnelli|Okay. Will try to focus on trivial docs PRs, so wumpus and sipa can take care about the corish ones.
539 2016-06-02 19:42:24	0|luke-jr|https://github.com/bitcoin/bitcoin/pull/7935 is ready IMO
540 2016-06-02 19:42:47	0|sipa|luke-jr: agree
541 2016-06-02 19:42:47	0|wumpus|the problem with doc pulls is usually that they get review comments but the author disappears for large spans of time
542 2016-06-02 19:43:10	0|sipa|luke-jr: will do final review and reack
543 2016-06-02 19:43:28	0|cfields_|luke-jr: that looked good to me last time I checked. I'll re-review as well.
544 2016-06-02 19:44:53	0|sipa|also #7825 is good
545 2016-06-02 19:45:27	0|sipa|and #7942
546 2016-06-02 19:46:23	0|jonasschnelli|Also have a look at https://github.com/bitcoin/bitcoin/pull/7946 (could speed up things a little bit)
547 2016-06-02 19:46:26	0|wumpus|#7942 has an unaddressed comment by sipa
548 2016-06-02 19:46:56	0|sipa|tiny nit :)
549 2016-06-02 19:47:21	0|jonasschnelli|nit is nit!
550 2016-06-02 19:47:38	0|wumpus|that's not always clear to me whether it should block merging
551 2016-06-02 19:47:47	0|wumpus|(I usually at least wait for the author to respond)
552 2016-06-02 19:48:09	0|sipa|the author is active, he probably just missed it
553 2016-06-02 19:48:16	0|sipa|jonasschnelli just pinged
554 2016-06-02 19:48:21	0|wumpus|ok good
555 2016-06-02 19:48:24	0|luke-jr|oh, topic: 0.11.next
556 2016-06-02 19:49:16	0|jonasschnelli|luke-jr, I guess we already discussed the 0.11 maintenance?
557 2016-06-02 19:49:17	0|wumpus|ok
558 2016-06-02 19:49:21	0|wumpus|#topic 0.11.next
559 2016-06-02 19:49:54	0|luke-jr|jonasschnelli: ?
560 2016-06-02 19:50:12	0|sipa|0.11 goes to critical fixes only when 0.13 is released, right?
561 2016-06-02 19:50:13	0|jtimon|luke-jr: 0.11.next is supposed to include csv but not segwit, right?
562 2016-06-02 19:50:33	0|jonasschnelli|I had in mind we we BP to 0.12, 0.13 and only security stuff to 0.11?
563 2016-06-02 19:50:37	0|luke-jr|jtimon: unless it gets delayed until segwit is merged, I guess
564 2016-06-02 19:50:53	0|luke-jr|sipa: unless someone decides to maintain it longer
565 2016-06-02 19:50:53	0|wumpus|is there any urgent reason to do a 0.11 release?
566 2016-06-02 19:51:00	0|luke-jr|wumpus: CSV support, at least
567 2016-06-02 19:51:05	0|wumpus|right
568 2016-06-02 19:51:20	0|jtimon|wumpus: is there any reason not to do it while things are backported and tested?
569 2016-06-02 19:51:24	0|gmaxwell|looking at the network I'm not seeing any evidence of need to maintain 0.11 extensively, also we called for people running older versions in operations and got crickets in response, AFAIK.
570 2016-06-02 19:51:36	0|wumpus|jtimon: developer overhead
571 2016-06-02 19:51:49	0|sipa|jtimon: is it tested?
572 2016-06-02 19:51:50	0|jtimon|wumpus: well, that's luke-jr's problem, isn't it?
573 2016-06-02 19:52:33	0|luke-jr|gmaxwell: we did? I don't recall seeing the "call for", and I know for a fact that Eligius relies on 0.11 for now
574 2016-06-02 19:52:58	0|jonasschnelli|88  0.11  nodes
575 2016-06-02 19:53:07	0|jtimon|sipa: I don't know, I'm not reviewing or testing myself, but if luke-jr gets review and testing...
576 2016-06-02 19:53:19	0|sipa|luke-jr: perhaps the time is better spent in upgrading eligius then :)
577 2016-06-02 19:53:29	0|luke-jr|jtimon: which is unlikely, hence the history of git/rc only stable stuff :P
578 2016-06-02 19:53:38	0|luke-jr|sipa: probably.
579 2016-06-02 19:53:49	0|gmaxwell|esp since master will hopefully have CPFP soon.
580 2016-06-02 19:53:51	0|luke-jr|jonasschnelli: what?
581 2016-06-02 19:53:56	0|wumpus|yes, interest in older major versions is extrememly low
582 2016-06-02 19:54:09	0|btcdrak|there is a backport PR for 0.11 for CSV etc. but we sort of semi decided back then it was not urgent and much more risky.
583 2016-06-02 19:54:14	0|luke-jr|I see 1768 0.11 nodes.
584 2016-06-02 19:54:28	0|btcdrak|the BIP68 backport in particular is complex
585 2016-06-02 19:54:41	0|gmaxwell|well in particular, interest in _updates_ for old versions is low...
586 2016-06-02 19:54:41	0|jtimon|my only point is that we shouldn't use the "we only promise to maintain the last 2 versions" as an artificial limitation beyond review and testing. If people are interested in working on that...
587 2016-06-02 19:54:55	0|wumpus|gmaxwell: yes that's what I mean...
588 2016-06-02 19:54:59	0|luke-jr|we should remove the promise if we're not going to uphold it.
589 2016-06-02 19:55:13	0|wumpus|jtimon: the problem is that people are not interested
590 2016-06-02 19:55:18	0|gmaxwell|what promise?
591 2016-06-02 19:55:26	0|jtimon|well "promise"
592 2016-06-02 19:55:35	0|gmaxwell|also, not "not going"-- not able.. without people to test you really can't provide good releases.
593 2016-06-02 19:55:48	0|jtimon|wumpus: by people you mean users or reviewers/testers?
594 2016-06-02 19:55:50	0|gmaxwell|not doing someone a service to put out a barely tested update.
595 2016-06-02 19:55:57	0|wumpus|I mean if luke-jr really wants to handle a release by himself I'm not going to protest
596 2016-06-02 19:56:05	0|gmaxwell|^ agreed.
597 2016-06-02 19:56:06	0|luke-jr|https://bitcoincore.org/en/lifecycle/ mentions something; whether promise or able or not, it should be updated if we can't do it
598 2016-06-02 19:56:10	0|btcdrak|the CSV backport PR was https://github.com/bitcoin/bitcoin/pull/7716
599 2016-06-02 19:56:22	0|btcdrak|we did pretty much decide not to merge it.
600 2016-06-02 19:56:24	0|luke-jr|wumpus: I can't get testing/reviews by myself.
601 2016-06-02 19:56:28	0|jonasschnelli|luke-jr: sorry,.. wrong file: we have 743 0.11x nodes and 1786 0.12.x nodes... so yes. CSV for 0.11 makes sense.
602 2016-06-02 19:56:41	0|luke-jr|I can maintain stable branches, but releases seem unlikely to work out at this point
603 2016-06-02 19:56:55	0|wumpus|but there's so much happening on master right now, and 0.13 release is near, I can't promise I will be able to spend any time on it (except gitian building / uploading executables)
604 2016-06-02 19:57:23	0|jonasschnelli|Yes. 0.11 is certainly not something for wumpus (would be a waste of his time)
605 2016-06-02 19:57:58	0|gmaxwell|Without people interested in using it, we can't get much platform qualification which is a lot of the difference between a branch and a release.
606 2016-06-02 19:57:59	0|wumpus|so if you want to do this: please create your own 0.11 branch, tag, do the release notes etc
607 2016-06-02 19:58:00	0|sipa|jtimon: i have 1093 'good' 0.11 nodes
608 2016-06-02 19:58:10	0|sipa|eh, jonasschnelli:
609 2016-06-02 19:58:33	0|jonasschnelli|good is not good enough...
610 2016-06-02 19:58:34	0|jonasschnelli|cat dnsseed.dump | grep " 100.00% 100.00% 100.00% " | grep "Satoshi:0.11." | wc -l
611 2016-06-02 19:59:05	0|sipa|anyway, besided the point
612 2016-06-02 19:59:15	0|sipa|we can't do releases without people interested in running and testing
613 2016-06-02 19:59:17	0|wumpus|yes, meeting time over
614 2016-06-02 19:59:21	0|sipa|oh, that too
615 2016-06-02 19:59:24	0|wumpus|#endmeeting
616 2016-06-02 19:59:25	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-02-19.00.log.html
617 2016-06-02 19:59:25	0|lightningbot|Meeting ended Thu Jun  2 19:59:24 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
618 2016-06-02 19:59:25	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-02-19.00.html
619 2016-06-02 19:59:25	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-02-19.00.txt
620 2016-06-02 19:59:35	0|jtimon|maybe we can merge it into the 0.11 branch without doing a release?
621 2016-06-02 20:00:01	0|wumpus|jtimon: sure. luke-jr can run his own 0.11 branch, I could just take that over
622 2016-06-02 20:00:18	0|gmaxwell|could be done, I suppose. But thing is: soft forks are more or less safe to run without, but a broken update may be less safe.
623 2016-06-02 20:00:28	0|gmaxwell|not that I think there is a lot of risk there.
624 2016-06-02 20:00:38	0|jtimon|and if it ever gets tested, release, otherwise there's never a 0.11.next
625 2016-06-02 20:00:42	0|wumpus|well if no one runs it, it doesn't create much risk either :)
626 2016-06-02 20:00:57	0|gmaxwell|Good point.
627 2016-06-02 20:01:49	0|luke-jr|wumpus: should I continue to maintain stable branches in a separate repo (the old one was on Gitorious which is dead, so a new location needs deciding if so), or would it make sense to do it on the main repo now (would require push access for me, at least in the stable branches)?
628 2016-06-02 20:01:59	0|luke-jr|[20:00:18] <gmaxwell> could be done, I suppose. But thing is: soft forks are more or less safe to run without, but a broken update may be less safe. <-- my main concern with backporting of the recent softforks
629 2016-06-02 20:02:43	0|jtimon|can't we just merge PRs in the 0.11 branch in the main repo?
630 2016-06-02 20:02:43	0|wumpus|luke-jr: well you don't strictly need push access; I could just pull the 0.11 branch from your repo when you say so
631 2016-06-02 20:02:48	0|btcdrak|luke-jr: morcos specific concern was the safety of BIP68 backport
632 2016-06-02 20:02:54	0|luke-jr|wumpus: that'd work too I guess
633 2016-06-02 20:03:00	0|btcdrak|the backports were done in #7716
634 2016-06-02 20:03:05	0|jtimon|or that, I'll shut up, you people coordinate
635 2016-06-02 20:03:52	0|btcdrak|The codebase is significantly different between 0.11 and 0.12 with regards to BIP68
636 2016-06-02 20:03:58	0|luke-jr|it probably would make sense to have a separate repo for stable in general, though, so we can't accidentally confuse PRs against the wrong branch
637 2016-06-02 20:05:21	0|wumpus|at least the github merge script now automatically gets the branch to merge against from github
638 2016-06-02 20:05:40	0|gmaxwell|luke-jr: is there any thing I could help do to get eligius off of 0.11 and to 0.12.1  (and maybe master with CPFP?)
639 2016-06-02 20:07:20	0|luke-jr|gmaxwell: my current target is Knots 0.12.1 including CPFP there, so the big step is backporting CPFP in a way that can be turned on/off (which AIUI, the CPFP dep makes easier); I don't think there's a good way to divide this work, however
640 2016-06-02 20:08:31	0|gmaxwell|luke-jr: ugh.
641 2016-06-02 20:08:59	0|gmaxwell|I don't see what benefit you get from 0.12.1 with such a large and invasive backport.
642 2016-06-02 20:09:37	0|luke-jr|as opposed to everything else in master? :x
643 2016-06-02 20:10:48	0|gmaxwell|which has a lot more eyes on it, and in the mining relevant codepaths, the changes for CPFP are probably the bulk of the changes.
644 2016-06-02 20:11:08	0|gmaxwell|also, look ahead a bit, and you'd have to forward port that backport onto segwit.
645 2016-06-02 20:13:36	0|luke-jr|hmm
646 2016-06-02 20:15:06	0|BakSAj|i understand the need for backporting in enterprise software, where upgrades might get messy, but what is the exact point in btc where process is quite simple...?
647 2016-06-02 20:15:10	0|luke-jr|not sure it'd be less work to forward-port Knots to master either, though
648 2016-06-02 20:15:54	0|luke-jr|BakSAj: consensus systems carry even more risk in upgrades, than enterprise
649 2016-06-02 20:16:01	0|gmaxwell|BakSAj: there are many large businesses that use Bitcoin too, and some that have complex customizations.
650 2016-06-02 20:16:05	0|sipa|luke-jr: what other kinds of changes does Knots have?
651 2016-06-02 20:16:44	0|gmaxwell|BakSAj: unfortunately, though we know these deployments exist-- we seldom hear from people involved with them.
652 2016-06-02 20:18:43	0|luke-jr|sipa: http://bitcoinknots.org/ has the full list, but relevant to Eligius.. *skims over list* #7149, #7533, and spamfilter; so maybe easier than backporting CPFP
653 2016-06-02 20:18:48	0|BakSAj|i wonder if they do patching
654 2016-06-02 20:19:09	0|BakSAj|otherwise its just a waste of dev that can go to master version
655 2016-06-02 20:19:33	0|luke-jr|would be nice to get #7149 reviewed and merged finally.
656 2016-06-02 20:20:59	0|btcdrak|This was the summary regarding the backports, for the record https://bitcoincore.org/en/meetings/2016/03/31/#softfork-backports
657 2016-06-02 20:28:00	0|BakSAj|ok, thanks for clarification
658 2016-06-02 20:29:20	0|BakSAj|i hope 0.12.1 will activate soon, so you guys can move on with segwit and get lightning finally
659 2016-06-02 20:29:54	0|BakSAj|anybody happen to know when e.g. f2pool moves to 0.12.1 ?
660 2016-06-02 22:45:45	0|GitHub51|13bitcoin/06master 140bf6f30 15Pedro Branco: Prevent multiple calls to ExtractDestination
661 2016-06-02 22:45:45	0|GitHub51|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/ec45cc5e2766...f972b04d63eb
662 2016-06-02 22:45:46	0|GitHub51|13bitcoin/06master 14f972b04 15Pieter Wuille: Merge #7825: Prevent multiple calls to ExtractDestination...
663 2016-06-02 22:45:50	0|GitHub30|[13bitcoin] 15sipa closed pull request #7825: Prevent multiple calls to ExtractDestination (06master...06enhancement/prevent-multiple-calls-extractdestination) 02https://github.com/bitcoin/bitcoin/pull/7825
664 2016-06-02 23:27:14	0|GitHub138|13bitcoin/06master 149805f4a 15Kaz Wesley: mapNextTx: use pointer as key, simplify value...
665 2016-06-02 23:27:14	0|GitHub138|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/f972b04d63eb...a82f03393a32
666 2016-06-02 23:27:15	0|GitHub138|13bitcoin/06master 14a82f033 15Pieter Wuille: Merge #7997: replace mapNextTx with slimmer setSpends...
667 2016-06-02 23:27:19	0|GitHub69|[13bitcoin] 15sipa closed pull request #7997: replace mapNextTx with slimmer setSpends (06master...06setSpends) 02https://github.com/bitcoin/bitcoin/pull/7997