1 2016-09-27 02:39:38	0|GitHub23|[13bitcoin] 15fanquake opened pull request #8819: [depends] Boost 1.61.0 (06master...06depends-boost-1-61-0) 02https://github.com/bitcoin/bitcoin/pull/8819
  2 2016-09-27 04:38:01	0|GitHub138|[13bitcoin] 15fanquake opened pull request #8820: [depends] Fix Qt compilation with Xcode 8 (06master...06depends-qt-xcoderun) 02https://github.com/bitcoin/bitcoin/pull/8820
  3 2016-09-27 05:00:55	0|luke-jr|what's holding back https://github.com/bitcoin/bitcoin/pull/8357 ?
  4 2016-09-27 06:47:53	0|jonasschnelli|wumpus: regarding the UTXO set cursor you have implemented in #7756...
  5 2016-09-27 06:48:20	0|jonasschnelli|once you create the cursor, new changes won't affect itteration?
  6 2016-09-27 07:44:20	0|GitHub131|[13bitcoin] 15MarcoFalke opened pull request #8821: [qt] sync-overlay: Don't block during reindex (06master...06Mf1609-qtSyncReindex) 02https://github.com/bitcoin/bitcoin/pull/8821
  7 2016-09-27 10:43:51	0|wumpus|jonasschnelli: indeed
  8 2016-09-27 10:44:06	0|wumpus|it uses a leveldb snapshot
  9 2016-09-27 10:44:48	0|wumpus|the idea is that you can do a background backup/downlaod/analysis
 10 2016-09-27 10:46:38	0|wumpus|does it use the utxo cursor to iterate over the utxo set? if so, you don't need a lock
 11 2016-09-27 10:47:19	0|wumpus|getutxosetinfo or whatever it's called also doesn't take a lock, at least not during the crunching phase
 12 2016-09-27 10:47:37	0|luke-jr|it isn't implemented sanely yet afaik, just pondering how the ideal impl would be
 13 2016-09-27 11:14:32	0|dinao|What is the purpose of the version-field in transactions?
 14 2016-09-27 11:20:03	0|Yogh_|when two blocks at the same height (at the tip) arrive in a Core node, does Core choose the first-seen block or the highest-work block as its chaintip of preference?
 15 2016-09-27 11:20:35	0|wumpus|always the highest total work, also this is a general #bitcoin question
 16 2016-09-27 11:22:26	0|GitHub136|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/2f71490d2179...6e54c85439b6
 17 2016-09-27 11:22:27	0|GitHub136|13bitcoin/06master 140637b02 15Johnson Lau: Ping regularly in p2p-segwit.py to keep connection alive...
 18 2016-09-27 11:22:28	0|GitHub136|13bitcoin/06master 146e54c85 15Wladimir J. van der Laan: Merge #8803: Ping regularly in p2p-segwit.py to keep connection alive...
 19 2016-09-27 11:22:38	0|GitHub65|[13bitcoin] 15laanwj closed pull request #8803: Ping regularly in p2p-segwit.py to keep connection alive (06master...06patch-17) 02https://github.com/bitcoin/bitcoin/pull/8803
 20 2016-09-27 11:24:17	0|sipa|Yogh_: unless there is a retarget inside the reorged blkcks, the amount of work in both blocks will be the same
 21 2016-09-27 11:25:10	0|sipa|Yogh_: so yes, core chooses the highest work, but in practice the work will be the same, and we use first-seen as tie breaker
 22 2016-09-27 11:26:12	0|sipa|dinao: bip68 uses it
 23 2016-09-27 11:26:15	0|GitHub49|13bitcoin/06master 144731cab 15Pavel Janík: Do not shadow variables
 24 2016-09-27 11:26:15	0|GitHub49|13bitcoin/06master 14920ca1f 15Wladimir J. van der Laan: Merge #8655: Do not shadow variables (trivials)...
 25 2016-09-27 11:26:15	0|GitHub49|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/6e54c85439b6...920ca1f0bf0b
 26 2016-09-27 11:26:24	0|GitHub42|[13bitcoin] 15laanwj closed pull request #8655: Do not shadow variables (trivials) (06master...0620160902_Wshadow_trivials) 02https://github.com/bitcoin/bitcoin/pull/8655
 27 2016-09-27 11:26:35	0|Yogh_|okay thanks
 28 2016-09-27 11:27:38	0|dinao|sipa: Can I ignore what nSequence says if I use a certain version of the transaction?
 29 2016-09-27 11:28:29	0|sipa|dinao: nSequence still has a meaning (for determining finality) for nVersion=1 transactions
 30 2016-09-27 11:29:51	0|dinao|sipa: Ok, so nVersion=1 transactions are still standard?
 31 2016-09-27 11:29:57	0|sipa|absolutely
 32 2016-09-27 11:30:18	0|dinao|sipa: Thanks for the clarifications!
 33 2016-09-27 11:30:18	0|sipa|as long as they're final
 34 2016-09-27 11:30:52	0|sipa|(which means either nlocktime=0 or all nsequence values maximal)
 35 2016-09-27 12:06:38	0|luke-jr|… or nlocktime < median timestamp or block height
 36 2016-09-27 12:11:38	0|sipa|luke-jr: right!
 37 2016-09-27 12:12:49	0|GitHub29|[13bitcoin] 15laanwj opened pull request #8822: net: Consistent checksum handling (06master...062016_09_normalize_checksum_handling) 02https://github.com/bitcoin/bitcoin/pull/8822
 38 2016-09-27 13:08:34	0|GitHub120|[13bitcoin] 15laanwj opened pull request #8823: doc: Add privacy recommendation when running hidden service (06master...062016_09_tor_recommendation) 02https://github.com/bitcoin/bitcoin/pull/8823
 39 2016-09-27 13:11:14	0|GitHub65|[13bitcoin] 15laanwj pushed 12 new commits to 060.13: 02https://github.com/bitcoin/bitcoin/compare/254e990ce5c3...a916677ace1c
 40 2016-09-27 13:11:14	0|GitHub7|[13bitcoin] 15laanwj closed pull request #8815: Backports for 0.13.1 (060.13...062016_09_backports_0_13_1) 02https://github.com/bitcoin/bitcoin/pull/8815
 41 2016-09-27 13:11:15	0|GitHub65|13bitcoin/060.13 141672225 15Pieter Wuille: Do not store witness txn in rejection cache...
 42 2016-09-27 13:11:15	0|GitHub65|13bitcoin/060.13 14b394a96 15instagibbs: Add basic test for IsStandard witness transaction blinding...
 43 2016-09-27 13:11:16	0|GitHub65|13bitcoin/060.13 14a5ec248 15Johnson Lau: Remove createwitnessaddress...
 44 2016-09-27 13:20:50	0|GitHub142|13bitcoin/06master 1442f6aed 15Wladimir J. van der Laan: tests: Add exception error message for JSONRPCException...
 45 2016-09-27 13:20:50	0|GitHub142|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/920ca1f0bf0b...14e8f9916beb
 46 2016-09-27 13:20:51	0|GitHub142|13bitcoin/06master 1414e8f99 15Wladimir J. van der Laan: Merge #8810: tests: Add exception error message for JSONRPCException...
 47 2016-09-27 13:21:05	0|GitHub61|[13bitcoin] 15laanwj closed pull request #8810: tests: Add exception error message for JSONRPCException (06master...062016_09_tests_rpc_error) 02https://github.com/bitcoin/bitcoin/pull/8810
 48 2016-09-27 14:20:57	0|GitHub171|[13bitcoin] 15jnewbery opened pull request #8824: refactor TxToJSON() and ScriptPubKeyToJSON() (06master...06JSON_refactor) 02https://github.com/bitcoin/bitcoin/pull/8824
 49 2016-09-27 14:33:49	0|GitHub37|13bitcoin/06master 1494a34a5 15maiiz: Fix relaypriority calculation error
 50 2016-09-27 14:33:49	0|GitHub37|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/14e8f9916beb...e9d5f6fec8fc
 51 2016-09-27 14:33:50	0|GitHub37|13bitcoin/06master 14e9d5f6f 15Wladimir J. van der Laan: Merge #8357: [mempool] Fix relaypriority calculation error...
 52 2016-09-27 14:33:58	0|GitHub169|[13bitcoin] 15laanwj closed pull request #8357: [mempool] Fix relaypriority calculation error (06master...06maiiz-patch-1) 02https://github.com/bitcoin/bitcoin/pull/8357
 53 2016-09-27 15:10:33	0|GitHub181|13bitcoin/06master 14c72c5b1 15Johnson Lau: Make non-minimal OP_IF/NOTIF argument non-standard for P2WSH
 54 2016-09-27 15:10:33	0|GitHub181|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e9d5f6fec8fc...5a4f6d72e615
 55 2016-09-27 15:10:34	0|GitHub181|13bitcoin/06master 145a4f6d7 15Wladimir J. van der Laan: Merge #8526: Make non-minimal OP_IF/NOTIF argument non-standard for P2WSH...
 56 2016-09-27 15:10:44	0|GitHub171|[13bitcoin] 15laanwj closed pull request #8526: Make non-minimal OP_IF/NOTIF argument non-standard for P2WSH (06master...06minimalif) 02https://github.com/bitcoin/bitcoin/pull/8526
 57 2016-09-27 15:13:25	0|wumpus|only three 0.13.1-backport pulls open, we're getting there... https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+label%3A%22Needs+backport%22
 58 2016-09-27 15:18:06	0|sipa|going through them
 59 2016-09-27 15:25:34	0|wumpus|8634 seems ready for merge but needs rebase
 60 2016-09-27 15:26:18	0|wumpus|probably because of #8526
 61 2016-09-27 15:32:05	0|btcdrak|jl2012 is rebasing now
 62 2016-09-27 15:33:54	0|MarcoFalke|btcdrak: https://github.com/bitcoin-core/bitcoincore.org/pull/217 (website is broken)
 63 2016-09-27 15:34:06	0|MarcoFalke|the meeting shows up on the main page
 64 2016-09-27 15:34:58	0|btcdrak|oh. pushed
 65 2016-09-27 15:43:02	0|jl2012|yes, waiting for travis
 66 2016-09-27 15:47:57	0|wumpus|great
 67 2016-09-27 15:48:28	0|jl2012|#8499 is replaced with the policy only version
 68 2016-09-27 15:53:04	0|jl2012|just a nit: we should change the name of SIGVERSION to SCRIPTVERSION (I think we talked about it Zurich)
 69 2016-09-27 15:54:14	0|jl2012|it is the script, not the signature, determining the behaviour
 70 2016-09-27 15:54:45	0|GitHub3|13bitcoin/06master 14e41bd44 15Johnson Lau: Add policy: null signature for failed CHECK(MULTI)SIG
 71 2016-09-27 15:54:45	0|GitHub3|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/5a4f6d72e615...fc4f4547b7f6
 72 2016-09-27 15:54:46	0|GitHub3|13bitcoin/06master 14fc4f454 15Wladimir J. van der Laan: Merge #8634: Add policy: null signature for failed CHECK(MULTI)SIG...
 73 2016-09-27 15:54:55	0|GitHub147|[13bitcoin] 15laanwj closed pull request #8634: Add policy: null signature for failed CHECK(MULTI)SIG (06master...06nullfail) 02https://github.com/bitcoin/bitcoin/pull/8634
 74 2016-09-27 15:57:13	0|btcdrak|\o/
 75 2016-09-27 15:59:05	0|jl2012|#8499 is trivial. What is the progress of #8393 compact block?
 76 2016-09-27 16:00:36	0|sdaftuar|jl2012: i think it's done or close to done.  could be merged as-is, or with some tests, or with some minor improvements -- not sure what sipa prefers to do, but i'm fine with any of those options
 77 2016-09-27 16:01:47	0|jl2012|sdaftuar: thanks, #8499 is redone based on your suggestions
 78 2016-09-27 16:01:56	0|sdaftuar|jl2012: cool, i'll take a look
 79 2016-09-27 16:03:12	0|sipa|sdaftuar: i'll go through your suggestions later today
 80 2016-09-27 18:17:43	0|sipa|cfields_: does this mean we could build reproducible binaries, directly from depends/, without gitian?
 81 2016-09-27 18:20:06	0|sipa|cfields_: would you consider that to be future work?
 82 2016-09-27 18:20:31	0|sipa|(making it deterministic without gitian)
 83 2016-09-27 18:20:36	0|wumpus|cfields_: you mean, fetch pre-built binaries? that seems like a security risk
 84 2016-09-27 18:21:05	0|cfields_|sipa: could be, but I think it'd require a new approach. It essentially needs a chroot at minimum, I think
 85 2016-09-27 18:21:33	0|wumpus|sipa: I think you need some kind of controlled environment for deterministic building, whether it a chroot or LXC container
 86 2016-09-27 18:21:44	0|wumpus|sipa: otherwise there's just too much factors that can interfere
 87 2016-09-27 18:22:09	0|cfields_|wumpus: right, which is why we'd want them built with gitian. The download would look for a specific pre-generated result and checksum. Same as our osx toolchain download now.
 88 2016-09-27 18:22:50	0|cfields_|wumpus: also note that the toolchains are chained. So the old one always builds the new one.
 89 2016-09-27 18:23:51	0|cfields_|wumpus: again, I'm not married to it. I just wanted to go through it to see what it would take. If you'd prefer a different approach, or not bothering, I'm fine with that. The busted mingw toolchain from Ubuntu just made me grumpy :)
 90 2016-09-27 18:24:55	0|wumpus|cfields_: well I think building the toolchain to build with, certainly for windows makes sense
 91 2016-09-27 18:25:48	0|cfields_|wumpus: also worth noting that they're stand-alone and relocatable. So they're still generally useful outside of depends
 92 2016-09-27 18:26:33	0|wumpus|I just think that outside of gitian, depends downloading binaries is a bit questionable
 93 2016-09-27 18:26:45	0|wumpus|it's not what I would expect at least
 94 2016-09-27 18:27:07	0|cfields_|wumpus: well, it could default to self-building I suppose
 95 2016-09-27 18:27:20	0|cfields_|no reason not to, other than it takes a long time.
 96 2016-09-27 18:27:36	0|wumpus|I think it should default to using the toolchain provided by the user, unless specified otherwise
 97 2016-09-27 18:28:10	0|wumpus|I mean *generally* if you cross compile you have a toolchain and want to use that
 98 2016-09-27 18:28:21	0|wumpus|the ubuntu situation is kind of fucked up
 99 2016-09-27 18:29:43	0|cfields_|wumpus: sure. But the question is: going forward, how do we specify the toolchains used for releases? I don't think we always want to be at the mercy of the latest $distro packages?
100 2016-09-27 18:31:50	0|wumpus|cfields_: I think we should distinguish two cases here a) gitian builds b) user's depends builds. For the gitian builds it's acceptable to use our own toolchain. Also for depends, if so chosen. But I don't think depends should start out fetching/building a toolchain by default
101 2016-09-27 18:32:33	0|wumpus|cfields_: an example, let's say I'm cross-compiling for ARM. I have my own toolchain which I've built myself specifically for the device I'm cross-compiling to. But I use the depends to build bitcoin's dependencies.
102 2016-09-27 18:32:54	0|wumpus|cfields_: I wouldn't expect it to start building a random ARM toolchain, then :)
103 2016-09-27 18:34:39	0|wumpus|or ubuntus with broken toolchain we should document how to use our own, alternative toolchain
104 2016-09-27 18:34:42	0|wumpus|+for
105 2016-09-27 18:34:44	0|cfields_|wumpus: yes. The more reasonable approach would probably be 2 processes. One to build our toolchains, the other to build our depends. One can be plugged into the other for gitian/travis.
106 2016-09-27 18:35:11	0|wumpus|at least until ubuntu has cleaned up their act...
107 2016-09-27 18:35:13	0|cfields_|(just by setting PATH)
108 2016-09-27 18:35:17	0|wumpus|right
109 2016-09-27 18:36:44	0|cfields_|ok. And in that case, we'd want them chained together to eliminate distro reliance, right?
110 2016-09-27 18:37:28	0|wumpus|for the gitian builds, absolutely
111 2016-09-27 18:37:48	0|wumpus|I completely agree with what you're doing, I just don't think it should be default for depends
112 2016-09-27 18:39:24	0|cfields_|ok
113 2016-09-27 18:41:26	0|cfields_|sipa: to answer your question, I'm torn. I think working on a deterministic process like that is interesting, but I think it's more correct and generally useful to do it at a higher level
114 2016-09-27 18:42:17	0|cfields_|higher level meaning: fix the tools as needed to allow determinism, then projects can provide their own minimal environments (or use a de-facto one) for stripping out the rest.
115 2016-09-27 18:42:38	0|cfields_|There are already several projects like that, I think I'd only be adding noise :)
116 2016-09-27 18:43:04	0|sipa|cfields_: ok, just asking :)
117 2016-09-27 18:47:05	0|GitHub86|[13bitcoin] 15MarcoFalke closed pull request #8809: WIP: [qt] rework sync-overlay (06master...06Mf1609-qtSyncInf) 02https://github.com/bitcoin/bitcoin/pull/8809
118 2016-09-27 18:48:15	0|wumpus|cfields_: yes we should strongly avoid duplicating other project's efforts
119 2016-09-27 18:48:36	0|wumpus|we have plenty of issues of our own
120 2016-09-27 18:49:59	0|wumpus|and way too few people to handle them...
121 2016-09-27 19:01:58	0|arubi|I'm noticing the same behavior change in my own parser after implementing segwit today: http://paste.debian.net/plainh/40b5ff00  -  is parsing supposed to fail on zero inputs txs now?
122 2016-09-27 19:02:35	0|sipa|no valid transaction can have zero inputs
123 2016-09-27 19:03:19	0|arubi|right, and that would be the case forever?
124 2016-09-27 19:03:44	0|sipa|yes, it's a consensus rule
125 2016-09-27 19:04:01	0|sipa|and changing it would introduce replay attacks to bitcoin
126 2016-09-27 19:04:29	0|sipa|bitcoin core uses some heuristics when parsing input for fundrawtransaction and decoderawtransaction to determine whether it's an incomplete non-segwit transaction instead
127 2016-09-27 19:04:50	0|sipa|but i expect that longer term we'll need to move away from using the same serialization for incomplete transactions
128 2016-09-27 19:05:10	0|sipa|it becomes very hard to hack things like partial signatures for more complicated scripts into it
129 2016-09-27 19:05:18	0|arubi|exactly
130 2016-09-27 19:06:14	0|morcos|what were we saying CPU SHA256 speed was in MB/s?
131 2016-09-27 19:06:28	0|sipa|150
132 2016-09-27 19:06:34	0|morcos|k, thx
133 2016-09-27 19:06:54	0|arubi|sipa, I see, so not really losing anything by not parsing transactions like those anymore, not that I ever used it for anything meaningful.  I'll try figuring out how to bail early.  thanks
134 2016-09-27 19:20:40	0|jonasschnelli|has the FIBER (relay network) any form of encryption or authentication?
135 2016-09-27 19:21:43	0|sipa|BlueMatt: ^
136 2016-09-27 19:22:08	0|sipa|(also, it's called FIBRE)
137 2016-09-27 19:22:25	0|jonasschnelli|Ah.. it's french :)
138 2016-09-27 19:23:16	0|sipa|no, it's Fast Internet Bitcoin Relay Engine :p
139 2016-09-27 19:23:27	0|sipa|i assume it is purely IP based, but I don't know
140 2016-09-27 19:23:50	0|jonasschnelli|Looking at the code... yes. I think pure IP based.
141 2016-09-27 19:24:16	0|sipa|it's also UDP, so BIP151 wouldn't easily apply
142 2016-09-27 19:24:40	0|jonasschnelli|So an ISP could easily withhold blocks form certain miners
143 2016-09-27 19:24:58	0|jonasschnelli|Yes. I'm bringing this up in my BIP151 talk at the SB
144 2016-09-27 19:47:42	0|BlueMatt|jonasschnelli: it does
145 2016-09-27 19:47:54	0|BlueMatt|it has a simple mac key which is a constant per connection
146 2016-09-27 19:48:04	0|BlueMatt|no encryption, just auth
147 2016-09-27 19:51:50	0|sipa|BlueMatt: ah nice
148 2016-09-27 19:52:02	0|sipa|no encryption makes sense, there is no private data anyway
149 2016-09-27 19:53:17	0|BlueMatt|sipa: the "addudpnode" stuff requires a "password" for each connection