1 2016-11-18T00:04:14  <sipa> BlueMatt: sure
  2 2016-11-18T00:04:36  <gmaxwell> 8ad0a328584b0be86df79c4335c043b0e3bbb2a380023fec55933f357b57edae
  3 2016-11-18T00:05:03  <sipa> BlueMatt: i was wrong about only needing a std::shared_block<const CBlock> and deserializing into it. You'll also need to add a deserialize_t constructor in CBlock (whose body can just be 'ss >> *this')
  4 2016-11-18T00:06:09  <sipa> petertodd: re twitter... i was certainly aware that something like segwit could be done in an extension block like way... what was new was that it was 1) doable 2) backward compatible with old wallets
  5 2016-11-18T00:08:52  <sipa> gmaxwell: ?
  6 2016-11-18T00:13:37  *** Cory has quit IRC
  7 2016-11-18T00:14:17  *** AdrianG has quit IRC
  8 2016-11-18T00:14:17  *** jyap has quit IRC
  9 2016-11-18T00:14:57  *** jyap has joined #bitcoin-core-dev
 10 2016-11-18T00:14:58  *** jyap has joined #bitcoin-core-dev
 11 2016-11-18T00:16:01  *** Pasha has joined #bitcoin-core-dev
 12 2016-11-18T00:16:11  *** AdrianG has joined #bitcoin-core-dev
 13 2016-11-18T00:18:32  <BlueMatt> sipa: ahh...well if its more of a patch I'm gonna skip it until you have it written
 14 2016-11-18T00:18:38  <BlueMatt> and, maybe #9014 will be merged first :p
 15 2016-11-18T00:18:40  <gribble> https://github.com/bitcoin/bitcoin/issues/9014 | Fix block-connection performance regression by TheBlueMatt · Pull Request #9014 · bitcoin/bitcoin · GitHub
 16 2016-11-18T00:22:55  *** Pasha is now known as Cory
 17 2016-11-18T00:36:15  *** laurentmt has joined #bitcoin-core-dev
 18 2016-11-18T00:36:39  *** laurentmt has quit IRC
 19 2016-11-18T00:37:36  <sipa> cfields: i don't know whether caching the result of a dereference actually has that much of an effect... there are no concurrency guarantees on shared_ptr dereferences, so i expect the compiler to just cache the result
 20 2016-11-18T00:37:44  <sipa> through common subexpression elimination
 21 2016-11-18T00:46:48  <cfields> sipa: hmm, I'd always assumed that dereferencing required an atomic operation, but a quick look says otherwise. Makes sense, since it's guaranteed to be in scope. TIL.
 22 2016-11-18T00:47:22  *** Chris_Stewart_5 has quit IRC
 23 2016-11-18T00:47:28  <sipa> cfields: using multiple shared_ptr objects that refer to the same pointed-to object is threadsafe
 24 2016-11-18T00:47:40  <sipa> cfields: using the same shared_ptr from multiple threads is not
 25 2016-11-18T00:51:08  <jtimon> sipa: did you change 9125 or just rebase?
 26 2016-11-18T00:51:39  <sipa> jtimon: both
 27 2016-11-18T00:51:52  <sipa> jtimon: i'll comment on the changes
 28 2016-11-18T00:52:06  <jtimon> cool, I tried https://github.com/sipa/bitcoin/compare/9bc6cbc4e24ef856ad4c803226378f276acc14ff...39e832c90012db03822f61009060712a47f7f81d but did work :p
 29 2016-11-18T00:53:10  <cfields> sipa: got it, thanks
 30 2016-11-18T00:53:43  <sipa> cfields: so as long as you're not creating/destroying/copying shared_ptr's, they are effectively identical to accessing a simple pointer
 31 2016-11-18T00:54:59  <cfields> sipa: I see that now. I had a pretty fundamental misunderstanding about the overhead. That's very cool.
 32 2016-11-18T01:01:30  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 33 2016-11-18T01:12:13  <BlueMatt> cfields: see pm?
 34 2016-11-18T01:14:53  <btcdrak> cfields: roasbeef said he's restarting those scripts
 35 2016-11-18T01:15:34  *** Chris_Stewart_5 has quit IRC
 36 2016-11-18T01:23:25  *** meownow has joined #bitcoin-core-dev
 37 2016-11-18T01:26:10  <cfields> btcdrak: thanks
 38 2016-11-18T01:26:22  <cfields> roasbeef: thanks too :)
 39 2016-11-18T01:31:08  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 40 2016-11-18T01:45:57  *** Chris_Stewart_5 has quit IRC
 41 2016-11-18T01:47:28  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 42 2016-11-18T01:56:44  *** abpa has quit IRC
 43 2016-11-18T01:57:00  *** crescendo has quit IRC
 44 2016-11-18T02:09:03  * jtimon re-asks for review on https://github.com/bitcoin/bitcoin/pull/8855
 45 2016-11-18T02:09:53  <sipa> jtimon: i was looking at it right now!
 46 2016-11-18T02:10:51  <jtimon> sipa: cool, but you're the one who already looked at it :p it was for the others
 47 2016-11-18T02:11:19  <jtimon> I mean, I'm definitely interested in kowing if the nits are solved
 48 2016-11-18T02:11:38  <jtimon> knowing
 49 2016-11-18T02:16:48  *** chjj has joined #bitcoin-core-dev
 50 2016-11-18T02:20:26  *** DigiByteDev has joined #bitcoin-core-dev
 51 2016-11-18T02:20:33  <roasbeef> hmm, chjj and I seem to be encountering some odd behavior with segwit enabled core nodes on testnet: they aren't including witness_tx inv's in their getdata's when fetching transactions, so they fetch witness output spending transactions without the witness data (though the service bit is set). this should cause an immediate rejecvt due to the clean-stack rules, but they keep accepting the txns, sending a delayed reject minutes afterwards
 52 2016-11-18T02:26:52  <sipa> roasbeef: they send MSG_TX getdatas instead of MSG_WITNESS_TX ?
 53 2016-11-18T02:27:11  <roasbeef> sipa: yeh
 54 2016-11-18T02:27:25  <chjj> sipa: yes. we have witness service bits, so do they. they repeatedly request our witness txs as non-witness.
 55 2016-11-18T02:27:27  <roasbeef> the delayed reject is nonstd-script-verify due to empty witness
 56 2016-11-18T02:27:40  <roasbeef> this then repeats as they aren't added to the reject cache
 57 2016-11-18T02:28:09  <chjj> sipa: seems to be both 13.0 and 13.1 nodes
 58 2016-11-18T02:29:54  <sipa> chjj, roasbeef: thanks, looking
 59 2016-11-18T02:30:27  <roasbeef> hypothesis: these nodes have been online since before segwit activated on testnet, and somehow the service bit they check isn't the most up-do-date version within GetFetchFlags
 60 2016-11-18T02:31:26  <sipa> found bug: getdatas of transactions sent in response to received transactions with missing inputs are always MSG_TX
 61 2016-11-18T02:31:57  <roasbeef> ahh yeah he's generating  really long chain of multi-sigs
 62 2016-11-18T02:32:01  <roasbeef> a really*
 63 2016-11-18T02:32:03  <chjj> oh, haha
 64 2016-11-18T02:32:11  <chjj> yeah, 3k nested transactions
 65 2016-11-18T02:32:53  <chjj> yeah, that would do it. potential dos vector found i guess. i should spam the network more often. :)
 66 2016-11-18T02:33:16  <sipa> thank you so much
 67 2016-11-18T02:33:17  * roasbeef giggles
 68 2016-11-18T02:34:31  <gmaxwell> yea, thats an issue.
 69 2016-11-18T02:35:19  <gmaxwell> We just added the orphan fetching in 0.13, so it won't work with witness txn. Considering that we've managed to go this long without having that orphan fetching at all, the world won't end. But that'll be good to get fixed in 0.13.2.
 70 2016-11-18T02:35:32  <gmaxwell> chjj, roasbeef thanks for finding that!!
 71 2016-11-18T02:36:05  <sipa> what do you mean by 3k nester transactions? if that's the length of the chain, we won't ever accept that into the mempool
 72 2016-11-18T02:36:06  <gmaxwell> chjj: I don't know what 3k nested txn means, but we won't take an unconfirmed chain longer than 25 in the mempool.
 73 2016-11-18T02:37:03  <chjj> gmaxwell sipa: no problem. we were sitting here for the past hour dumbfounded. glad we figured it out here.
 74 2016-11-18T02:37:22  <roasbeef> he means that he's generating a really long chain, they accept up to 25 (or reject them), but then the remainder are sent but at that point they're have orphan inputs from their PoV
 75 2016-11-18T02:37:54  <chjj> sipa: yeah, but it's a bunch of orphans. too-long-mempool-chain isn't checked for those i guess.
 76 2016-11-18T02:38:46  <gmaxwell> yea, doesn't really check any of the consistency, orphan pool is mostly a big bag of transactions.
 77 2016-11-18T02:38:59  <gmaxwell> And the 'fetch missing parents' is really just treating the orphan transaction like an implicit inv.
 78 2016-11-18T02:39:06  <chjj> yeah
 79 2016-11-18T02:39:37  <chjj> i was just signing a bunch of nested txs because roasbeef wanted me to. he wanted some big witness blocks. :)
 80 2016-11-18T02:39:49  <roasbeef> yeh, I put him up to it ;)
 81 2016-11-18T02:39:50  <chjj> wrote a script to endlessly sign and broadcast them
 82 2016-11-18T02:40:44  <sipa> filed an issue
 83 2016-11-18T02:40:48  <roasbeef> dope
 84 2016-11-18T02:42:40  *** Giszmo has quit IRC
 85 2016-11-18T02:57:24  *** To7 has joined #bitcoin-core-dev
 86 2016-11-18T03:13:26  *** Alopex has quit IRC
 87 2016-11-18T03:14:32  *** Alopex has joined #bitcoin-core-dev
 88 2016-11-18T03:17:26  *** meownow has quit IRC
 89 2016-11-18T03:27:10  *** abpa has joined #bitcoin-core-dev
 90 2016-11-18T03:28:19  <bitcoin-git> [bitcoin] TheBlueMatt reopened pull request #8930: Move orphan processing to ActivateBestChain (master...net_processing_3) https://github.com/bitcoin/bitcoin/pull/8930
 91 2016-11-18T03:29:23  <BlueMatt> ^ last pull before the final main.cpp split :)
 92 2016-11-18T03:29:45  <BlueMatt> there are some minor fixes in the main.cpp split pull, but should be easy-ish to review
 93 2016-11-18T03:30:11  *** crescendo has joined #bitcoin-core-dev
 94 2016-11-18T03:30:25  <BlueMatt> and they seem to be getting smaller and smaller as we go :)
 95 2016-11-18T03:31:25  *** Chris_Stewart_5 has quit IRC
 96 2016-11-18T03:35:06  <bitcoin-git> [bitcoin] TheBlueMatt opened pull request #9183: Final Preparation for main.cpp Split (master...net_processing_5) https://github.com/bitcoin/bitcoin/pull/9183
 97 2016-11-18T03:38:57  <crescendo> heh, glad I reconnected in time to see that one come across.  great work, @BlueMatt
 98 2016-11-18T03:39:21  *** Squidicuz has quit IRC
 99 2016-11-18T03:39:25  <sipa> BlueMatt: yay
100 2016-11-18T03:44:32  *** Squidicuz has joined #bitcoin-core-dev
101 2016-11-18T03:54:50  *** alpalp has joined #bitcoin-core-dev
102 2016-11-18T03:54:50  *** DigiByteDev has quit IRC
103 2016-11-18T04:10:48  *** alpalp has quit IRC
104 2016-11-18T04:22:11  *** DigiByteDev has joined #bitcoin-core-dev
105 2016-11-18T04:29:07  *** chjj has quit IRC
106 2016-11-18T04:31:15  *** DigiByteDev has quit IRC
107 2016-11-18T04:37:40  *** K4i7ok1d has joined #bitcoin-core-dev
108 2016-11-18T04:43:00  *** dermoth has joined #bitcoin-core-dev
109 2016-11-18T04:47:40  <dermoth> Hi there... I'm maintaining an opensource block explorer that calculate stats such as total bitcoins in circulations and btc days destroyed... Those stats are based not only on created coins but also permanently destroyed ones.
110 2016-11-18T04:47:52  <dermoth> Obviously there is no way to know about *all* destroyed coins, but there are obvious ways to destroy them which are factored in...
111 2016-11-18T04:48:00  <dermoth> Is there an official place to look for what should count as destroyed coins?
112 2016-11-18T04:57:16  <btcdrak> dermoth: there are some known unspendable addresses, like the counterparty burn, and 1bitcoineater etc. Certain type of counterparty and other type transactions which encode various messages are also known to be unspendable.
113 2016-11-18T05:04:11  *** DigiByteDev has joined #bitcoin-core-dev
114 2016-11-18T05:05:53  *** baldur has quit IRC
115 2016-11-18T05:08:57  *** DigiByteDev has quit IRC
116 2016-11-18T05:09:28  *** DigiByteDev has joined #bitcoin-core-dev
117 2016-11-18T05:21:20  *** DigiByteDev has quit IRC
118 2016-11-18T05:30:13  *** baldur has joined #bitcoin-core-dev
119 2016-11-18T05:30:15  <midnightmagic> dermoth: there are piles of proveable unspendable outputs, including e.g. the genesis block coinbase tx, the duplicated coinbase tx, the OP_RETURN spam, etc. As for the addresses -- the 1eater address and similar is probably not easily detected algorithmically. How can you tell for certain which addresses are constructed and which are in fact legitimate addresses.
120 2016-11-18T05:30:54  <sipa> dermoth: i list some of them here http://bitcoin.stackexchange.com/questions/38994/will-there-be-21-million-bitcoins-eventually
121 2016-11-18T05:31:22  <midnightmagic> dermoth: Meanwhile, how do you categorize e.g. those fees which were destroyed by miner underpays, and do you want to distinguish those from the fees+reward underpay that I did (which as far as I can tell I'm the only one to do it.)
122 2016-11-18T05:31:34  <midnightmagic> Is coin which never existed, actually destroyed?
123 2016-11-18T05:32:54  *** achow101 has joined #bitcoin-core-dev
124 2016-11-18T05:34:02  <midnightmagic> "Due to various bugs and miners experimenting with code, some blocks claim less than allowed."  <-- That is very kind of you sipa. :)
125 2016-11-18T05:34:22  <sipa> lock 124724 tried to intentionally claim 0.00000001 BTC less than allowed, but accidentally also failed to claim the fees, losing 0.01000001 BTC.
126 2016-11-18T05:34:28  <sipa> ^- that refers to you, i think
127 2016-11-18T05:35:27  <midnightmagic> sipa: In retrospect, if I knew then what I know now, I wouldn't have changed it--causing 0.00000001 to never have come into existence is a better way of doing it.
128 2016-11-18T05:35:38  <midnightmagic> BlueMatt: thanks for the idea!
129 2016-11-18T05:35:40  * midnightmagic tips hat
130 2016-11-18T05:49:20  *** bear13yte has joined #bitcoin-core-dev
131 2016-11-18T05:59:31  *** bear13yte has quit IRC
132 2016-11-18T06:00:41  *** wasi has quit IRC
133 2016-11-18T06:01:07  *** Alopex has quit IRC
134 2016-11-18T06:01:13  *** wasi has joined #bitcoin-core-dev
135 2016-11-18T06:02:12  *** Alopex has joined #bitcoin-core-dev
136 2016-11-18T06:11:03  *** JackH has quit IRC
137 2016-11-18T06:11:15  <dermoth> Thanks... I'm aware of how many ways coins can be destroyed... and indeed I never thought of underpay; I assumed reward+fee always matched first tx inputs (it could even have been enforced...)
138 2016-11-18T06:11:28  *** JackH has joined #bitcoin-core-dev
139 2016-11-18T06:12:02  <dermoth> I was just curious if there was an "official" list as far as stats calculations are concerned, so that everyone can compute stats the same way and more easily detect errors.
140 2016-11-18T06:12:50  <sipa> dermoth: i think that's hopeless
141 2016-11-18T06:13:19  <sipa> there may be 100000s or millions of BTC lost due to destroyed/forgotten/... wallets
142 2016-11-18T06:13:52  *** DigiByteDev has joined #bitcoin-core-dev
143 2016-11-18T06:18:23  *** jl2012 has quit IRC
144 2016-11-18T06:18:36  <dermoth> I know it's hopeless... between lost keys, valid address that were creates without the private side, custom scripts we have no way to verify they'll ever be usable.... That why I think there should be an official list of ways to destroy coins... I think underpay, OP_RETURN, null address, genesys/dup coinbases for a start... maybe addresses that are provably undependable (i.e. you can quickly and mathematically prove there is no private key
145 2016-11-18T06:18:36  <dermoth> s).
146 2016-11-18T06:18:43  *** jl2012 has joined #bitcoin-core-dev
147 2016-11-18T06:19:32  <dermoth> I don't think we should start going into more complex address even if we know some of them are impossible to create as a key pair, because there is not clear limit where to stop
148 2016-11-18T06:22:38  *** Ylbam has quit IRC
149 2016-11-18T06:23:33  <dermoth> BTW, I proposed a long time ago that all unspent coins after x blocks (many years) could be scavenged and redistributed to miners as a way to recycle destroyed coins (avoid inavoidable depletion) and keep miner's fee higher. For some reason ppl rejected that idea withotu much thought.
150 2016-11-18T06:27:02  <dermoth> I think after a certain number of bitcoin cycles (210k blocks) we could scavenge all unspent coins from the oldest 210k block, put them in a pool and let miners siphon 1/210000th of that pool every block. At that point the older part of the chain could be completely dropped as it would no longer have any use, and pooling the fund would ensure miners get a predictable reward.
151 2016-11-18T06:29:14  <gmaxwell> sounds like a great reason to refuse to mine peoples' transactions near that boundary.
152 2016-11-18T06:29:43  <gmaxwell> You might want to assume less about what people have given thought to and haven't.
153 2016-11-18T06:30:23  <dermoth> well that is definitively a good point
154 2016-11-18T06:30:34  <rabidus> you would kill the "store of value" property of bitcoin
155 2016-11-18T06:30:46  <dermoth> and it wasn'T the reason given back then
156 2016-11-18T06:30:48  <rabidus> if i would need to move my voins from year to year just to ensure that i own them
157 2016-11-18T06:32:05  <dermoth> rabidus, what's wrong with that? but yeah, gmaxwell's point is quite an issue...
158 2016-11-18T06:32:26  <rabidus> if i might lose my coins just because i didn't move them, it is not very good store of value.
159 2016-11-18T06:35:55  <dermoth> right now these tx would be prioritized already... I guess the only way would be to add even further priority (ex no count toward block size, aggressive p2p forwarding...) and a system to reject blocks that include less than a specific % amount of the pool os these tx'es... And now I could understand why we wouldn'T want that
160 2016-11-18T06:37:26  <gmaxwell> "would be prioritized already" huh?
161 2016-11-18T06:37:33  <dermoth> if you know after how long you need to resend the coins, there's not excuses to loose them. I was thinking at least 10+ years before they would drop anyway
162 2016-11-18T06:38:04  <dermoth> tx that moves very old coins are prioritized aren't they?
163 2016-11-18T06:38:42  <dermoth> priority = sum(input_value_in_base_units * input_age)/size_in_bytes
164 2016-11-18T06:38:59  <rabidus> i love to put my bitcoins into trezor, and forget it into safe or somewhere, just to be found for my grand children after 20 years
165 2016-11-18T06:39:02  <rabidus> oops, it's empty.
166 2016-11-18T06:39:38  <dermoth> which - another think - I think tx with less outputs than inputs should be prioritized too, since they help reducing the utxo size
167 2016-11-18T06:40:37  <dermoth> or to find that tour trezor's no longed functional, and your paper backup's ink washed out
168 2016-11-18T06:42:03  <sipa> dermoth: there is only one rational prioritization rule, and that's fee per byte
169 2016-11-18T06:42:43  <sipa> in the past, a few policies have existed that permitted old/larger coins, but they're no longer used by miners
170 2016-11-18T06:42:55  <luke-jr> some miners still use them
171 2016-11-18T06:42:57  <gmaxwell> jonasschnelli: the coin control gui sorts amounts lexographically!
172 2016-11-18T06:43:15  <sipa> dermoth, rabidus: also, please take this to #bitcoin
173 2016-11-18T06:43:20  <dermoth> sipa, don't you think at equal size a tx that reduce the node's uxto size should have hither priority than one that increase it?
174 2016-11-18T06:43:50  * luke-jr thinks right now they sort by txid in that scenario
175 2016-11-18T06:43:54  <dermoth> yeah and my apologies; I though I was in #bitcoin-dev (not -core-)
176 2016-11-18T06:44:20  <sipa> dermoth: yes, i think they should. but the only way to make that happen is by having consensus rules that make that strategy actually rational for miners to follow
177 2016-11-18T06:44:38  <sipa> dermoth: which segwit improves upon (but not enough, imo)
178 2016-11-18T06:47:28  *** Alina-malina has quit IRC
179 2016-11-18T06:47:28  *** Alina-malina has joined #bitcoin-core-dev
180 2016-11-18T06:47:56  <luke-jr> or miners just decide to do the better thing
181 2016-11-18T06:51:24  <sipa> luke-jr: we should build a system that incentivizes the right behaviour, not just hope for it
182 2016-11-18T06:51:26  <jonasschnelli> gmaxwell: my CoinControl sorts it per value per default
183 2016-11-18T06:52:00  <jonasschnelli> On which column do you have the "sort arrow"?
184 2016-11-18T06:52:23  <luke-jr> sipa: protocol changes need consensus. we can't force them on people. but it only takes good willed miners to use pro-Bitcoin policys.
185 2016-11-18T06:54:19  <jonasschnelli> gmaxwell: Qt persists the last sort order and column.
186 2016-11-18T06:54:27  <sipa> luke-jr: if we're going to depend on miners beibg the judges of good and bad, i'd rather remove PoW, give them identities, and hold them accountable
187 2016-11-18T06:55:25  <luke-jr> that would also be a protocol change.
188 2016-11-18T06:55:35  <luke-jr> also, this isn't a matter of dependency
189 2016-11-18T06:56:02  <luke-jr> the system doesn't fail if miners choose bad policies. it just works better if they choose good ones.
190 2016-11-18T06:56:38  <luke-jr> and a better working system makes their bitcoins more valuable, so arguably it's already incentivised
191 2016-11-18T06:58:23  <sipa> in the same way that a central bank is incentivised to not destroy a country's economy
192 2016-11-18T07:00:16  *** dermoth has quit IRC
193 2016-11-18T07:00:24  <sipa> anyway, probably off topic here
194 2016-11-18T07:00:30  <luke-jr> all incentives come down to value anyway
195 2016-11-18T07:01:04  *** dermoth has joined #bitcoin-core-dev
196 2016-11-18T07:01:41  <luke-jr> eg, it would be pretty stupid for miners to fill blocks with 100% super-high-fee spam for months on end, if it meant their rewards devalued to zero at the same time
197 2016-11-18T07:05:30  <gmaxwell> jonasschnelli: if I click "amount" it swaps ascending and decending order, but the sort is not numeric.
198 2016-11-18T07:05:45  <gmaxwell> e.g. it goes 1 10 2.
199 2016-11-18T07:06:11  <jonasschnelli> gmaxwell: Ah.. I see your point...
200 2016-11-18T07:06:50  <jonasschnelli> gmaxwell: strange... works on my end.
201 2016-11-18T07:06:59  <gmaxwell> hm. qt difference perhaps?
202 2016-11-18T07:07:05  <jonasschnelli> 1 2.4 9 10 25
203 2016-11-18T07:07:17  <jonasschnelli> I'm using Qt5.7
204 2016-11-18T07:07:22  <jonasschnelli> Testing now on 5.6
205 2016-11-18T07:09:29  <jonasschnelli> Also works with Qt5.6.1 (gitian)
206 2016-11-18T07:09:36  <jonasschnelli> (OSX)
207 2016-11-18T07:11:18  <gmaxwell> 5.4.2 here. okay, well if it's just me then I won't worry about it!
208 2016-11-18T07:11:42  * jonasschnelli booting up Ubuntu
209 2016-11-18T07:14:54  <gmaxwell> Unrelated, I think the GUI interface that says "N hours behind" is sometimes misunderstood to mean that it will take N hours to catch up.
210 2016-11-18T07:14:59  <jonasschnelli> gmaxwell: Bug confirmed on Ubuntu with master built with gitian Qt5.6.1
211 2016-11-18T07:15:03  <gmaxwell> \O/
212 2016-11-18T07:15:15  <jonasschnelli> though... probably an upstream bug.
213 2016-11-18T07:15:32  <wumpus> don't call it upstream bug too soon, qt is pretty good at sorting :p
214 2016-11-18T07:15:43  <jonasschnelli> "probably"
215 2016-11-18T07:15:59  <jonasschnelli> But the fact that its working on OSX and not on Ubuntu makes me think its very likely upstream
216 2016-11-18T07:16:03  <gmaxwell> I should use the GUI more, it does a lot of things nicely.
217 2016-11-18T07:17:50  <jonasschnelli> sortView(COLUMN_AMOUNT_INT64, Qt::DescendingOrder);
218 2016-11-18T07:18:18  <wumpus> itemOutput->setText(COLUMN_AMOUNT_INT64, strPad(QString::number(out.tx->vout[out.i].nValue), 15, " ")); // padding so that sorting works correctly
219 2016-11-18T07:18:20  <jonasschnelli> Ah... there is a hack involves.
220 2016-11-18T07:18:23  <jonasschnelli> involved
221 2016-11-18T07:18:23  <wumpus> eh ... :-(
222 2016-11-18T07:19:03  <cfields> strPad(QString::number(out.tx->vout[out.i].nValue), 15, " ")); // padding so that sorting works correctly
223 2016-11-18T07:19:06  <cfields> bah!
224 2016-11-18T07:19:08  <cfields> beat me to it!
225 2016-11-18T07:19:37  <wumpus> I somehow don't think that's the canonical way to do that
226 2016-11-18T07:19:41  <jonasschnelli> Hey! Where is @Cozz...
227 2016-11-18T07:20:14  <wumpus> you shouldn't need to define extra hidden columns to get sorting right, IIRC you can give the model a separate data item that will be used for sorting
228 2016-11-18T07:20:28  <wumpus> but yes I don't think any of us ever deeply looked at that code
229 2016-11-18T07:20:30  <jonasschnelli> Yes.
230 2016-11-18T07:21:25  <jonasschnelli> The hack was probably made because of the QTreeWidgetItem
231 2016-11-18T07:21:26  <wumpus> it was not the prettiest code but works pretty well, generall
232 2016-11-18T07:21:36  <jonasschnelli> Which maybe has some differences internally over a QTableView
233 2016-11-18T07:23:02  <jonasschnelli> Qt code:
234 2016-11-18T07:23:02  <jonasschnelli> bool QTreeWidgetItem::operator<(const QTreeWidgetItem &other) const
235 2016-11-18T07:23:06  <jonasschnelli> return text(column) < other.text(column);
236 2016-11-18T07:23:07  <jonasschnelli> :(
237 2016-11-18T07:26:28  <wumpus> they can be subclassed though
238 2016-11-18T07:26:39  <jonasschnelli> Yes. Trying to do that.
239 2016-11-18T07:26:46  <jonasschnelli> But why is it working on OSX?
240 2016-11-18T07:27:25  <wumpus> maybe some event handling difference, causing the hidden column not to be used for sorting?
241 2016-11-18T07:27:37  <wumpus> either that or strPad(QString::number(out.tx->vout[out.i].nValue) returns something different on different OS but that soounds unlikely.
242 2016-11-18T07:28:29  * wumpus wonders why there's an inefficiently implemented strPad when Qt has a perfectly fine rightJustified() method on QString
243 2016-11-18T07:28:41  <Victorsueca> morning
244 2016-11-18T07:29:29  <jonasschnelli> hi
245 2016-11-18T07:30:59  <Victorsueca> how the hell does one remember so many Qt element calls?
246 2016-11-18T07:31:15  <sipa> Victorsueca: google is your friend
247 2016-11-18T07:31:30  <Victorsueca> yeah lol
248 2016-11-18T07:31:42  <wumpus> use the search/grep/google whatever you prefer
249 2016-11-18T07:32:37  <wumpus> you don't have to remember every detail, just where to find things when you need them
250 2016-11-18T07:33:11  <sipa> exactly, you remember what things are possible, and how to use those
251 2016-11-18T07:33:33  <sipa> you can always find the details of how to do them again later
252 2016-11-18T07:33:55  <Victorsueca> yeah that's what I do with linux commands
253 2016-11-18T07:34:12  *** jtimon has quit IRC
254 2016-11-18T07:35:20  <wumpus> jonasschnelli: most common suggestion seems indeed to be to override QTreeWidgetItem <
255 2016-11-18T07:36:21  <Victorsueca> but when you're coding google not always brings the best way to do something for your specific case
256 2016-11-18T07:36:50  <wumpus> oh sure there's still some skill involved
257 2016-11-18T07:38:55  <wumpus> most important is that you're able to judge whether something is a good solution or not, so you can reject bad ones
258 2016-11-18T07:41:28  <wumpus> jonasschnelli: so probably our tree widget item subclass should have int64 fields for the amount and date, which are used for sorting instead of the text in the column, for those columns
259 2016-11-18T07:41:41  *** K4i7ok1d has quit IRC
260 2016-11-18T07:41:53  *** jannes has joined #bitcoin-core-dev
261 2016-11-18T07:46:58  *** Ylbam has joined #bitcoin-core-dev
262 2016-11-18T07:47:15  <Lauda> https://bitcoincore.org/en/segwit_adoption/ minor mistake here:"(note signalling will start around the 20th November 2016) "
263 2016-11-18T07:48:22  <sipa> it'll start about an hour from now
264 2016-11-18T07:49:35  <gmaxwell> Lauda: yea, that was the projection at the time the text was written.
265 2016-11-18T07:49:38  <Lauda> Indeed. 8 blocks left
266 2016-11-18T07:52:13  <jonasschnelli> wumpus: yes. Working on a fix. Though, it not to most important thing. :)
267 2016-11-18T08:00:29  <btcdrak> Launda: thanks, will update
268 2016-11-18T08:14:54  *** roidster has quit IRC
269 2016-11-18T08:19:21  <Lauda> Good btcdrauk
270 2016-11-18T08:20:43  <cfields> BlueMatt: maybe we should discuss approaches? Seems we might have something different in mind for encryption
271 2016-11-18T08:20:58  <cfields> and sipa ^^
272 2016-11-18T08:24:27  *** DigiByteDev has quit IRC
273 2016-11-18T08:24:45  <BlueMatt> cfields: probably, but bedtime for me rn
274 2016-11-18T08:26:36  <cfields> BlueMatt: ok, np. I just re-read my comments and realized they could've sounded a bit hostile. Not meant to be, for sure. I went back and forth on different approaches, very open to something other than what I settled on.
275 2016-11-18T08:28:02  *** rubensayshi has joined #bitcoin-core-dev
276 2016-11-18T08:43:14  *** fanquake has joined #bitcoin-core-dev
277 2016-11-18T09:18:38  *** Guyver2 has joined #bitcoin-core-dev
278 2016-11-18T09:27:59  *** DigiByteDev has joined #bitcoin-core-dev
279 2016-11-18T09:41:33  *** CubicEarth has joined #bitcoin-core-dev
280 2016-11-18T09:43:23  *** windsok has quit IRC
281 2016-11-18T09:47:24  *** ubuntu330 has joined #bitcoin-core-dev
282 2016-11-18T09:50:29  *** ubuntu330 has quit IRC
283 2016-11-18T09:55:35  *** gns3 has joined #bitcoin-core-dev
284 2016-11-18T09:57:59  *** gielbier has joined #bitcoin-core-dev
285 2016-11-18T10:13:26  <bitcoin-git> [bitcoin] jonasschnelli opened pull request #9185: [Qt] fix coincontrol sort issue (master...2016/11/fix_cc_sort) https://github.com/bitcoin/bitcoin/pull/9185
286 2016-11-18T10:15:23  *** windsok has joined #bitcoin-core-dev
287 2016-11-18T10:20:51  *** molz has joined #bitcoin-core-dev
288 2016-11-18T10:21:43  *** mol has joined #bitcoin-core-dev
289 2016-11-18T10:23:10  *** moli has quit IRC
290 2016-11-18T10:25:38  *** molz has quit IRC
291 2016-11-18T10:59:29  *** laurentmt has joined #bitcoin-core-dev
292 2016-11-18T10:59:44  *** laurentmt has quit IRC
293 2016-11-18T11:16:15  *** DigiByteDev has quit IRC
294 2016-11-18T11:17:33  *** DigiByteDev has joined #bitcoin-core-dev
295 2016-11-18T11:18:58  *** CubicEarth has quit IRC
296 2016-11-18T12:07:51  *** kadoban has quit IRC
297 2016-11-18T12:13:43  <bitcoin-git> [bitcoin] laanwj opened pull request #9186: test: Fix use-after-free in scheduler tests (master...2016_11_scheduler_fix) https://github.com/bitcoin/bitcoin/pull/9186
298 2016-11-18T12:46:37  *** Giszmo has joined #bitcoin-core-dev
299 2016-11-18T13:04:30  *** fanquake has quit IRC
300 2016-11-18T13:14:01  *** Alopex has quit IRC
301 2016-11-18T13:15:07  *** Alopex has joined #bitcoin-core-dev
302 2016-11-18T13:21:59  *** chris2000 has joined #bitcoin-core-dev
303 2016-11-18T13:31:14  *** DigiByteDev has quit IRC
304 2016-11-18T13:35:01  *** laurentmt has joined #bitcoin-core-dev
305 2016-11-18T13:35:07  *** laurentmt has quit IRC
306 2016-11-18T14:00:16  *** laurentmt has joined #bitcoin-core-dev
307 2016-11-18T14:02:24  *** chris2000 has quit IRC
308 2016-11-18T14:04:02  *** chjj has joined #bitcoin-core-dev
309 2016-11-18T14:13:54  *** laurentmt1 has joined #bitcoin-core-dev
310 2016-11-18T14:14:44  *** MarcoFalke has joined #bitcoin-core-dev
311 2016-11-18T14:15:32  *** laurentmt has quit IRC
312 2016-11-18T14:15:44  *** laurentmt1 is now known as laurentmt
313 2016-11-18T14:25:15  *** cryptapus_afk has quit IRC
314 2016-11-18T14:27:24  *** laurentmt has quit IRC
315 2016-11-18T14:28:16  *** roidster has joined #bitcoin-core-dev
316 2016-11-18T14:31:14  *** Chris_Stewart_5 has joined #bitcoin-core-dev
317 2016-11-18T14:49:53  *** DigiByteDev has joined #bitcoin-core-dev
318 2016-11-18T15:04:23  *** Chris_Stewart_5 has quit IRC
319 2016-11-18T15:07:55  *** paveljanik has quit IRC
320 2016-11-18T15:13:09  *** cryptapus has joined #bitcoin-core-dev
321 2016-11-18T15:13:10  *** cryptapus has joined #bitcoin-core-dev
322 2016-11-18T15:19:58  *** Victorsueca has quit IRC
323 2016-11-18T15:20:29  *** Victorsueca has joined #bitcoin-core-dev
324 2016-11-18T15:20:43  *** Chris_Stewart_5 has joined #bitcoin-core-dev
325 2016-11-18T15:26:11  *** abpa has quit IRC
326 2016-11-18T15:38:10  <btcdrak> ping wumpus
327 2016-11-18T16:06:40  <jl2012> blocks mined by a real 0.13.1 comes with a witness commitment: https://www.blocktrail.com/BTC/tx/86eb9975fae041df063f7ac0a94847883243704a7d20fb7726ba14239895a129
328 2016-11-18T16:07:07  *** abpa has joined #bitcoin-core-dev
329 2016-11-18T16:07:21  <jl2012> which is not found in slush's segwit blocks: https://www.blocktrail.com/BTC/tx/24dfb97c80d41e9dd153581b907c9270f8acd8509480e3bcde22684104d771c6
330 2016-11-18T16:07:44  *** JWU42 has joined #bitcoin-core-dev
331 2016-11-18T16:08:15  <sipa> jl2012: 0.13.1 only creates a commitment is there is a witness txn in the block, i believe
332 2016-11-18T16:08:52  <jl2012> but there are already 2 blocks, from different miners, come with witness commitment
333 2016-11-18T16:09:27  <sipa> it depends on their own stack, and arguably before activation there should certaibly not be a commitment
334 2016-11-18T16:09:37  <jl2012> this one from an unknown miner: https://www.blocktrail.com/BTC/tx/c02b8e9c0321656a6ca429c3f38bed729b17347304aae9ce2b6454396621b1c1
335 2016-11-18T16:10:25  <jl2012> not from BTCC: https://www.blocktrail.com/BTC/tx/5030f76f6411733458fa60fb706a9b2e0e7a3affd535004339482c42ec0a83d6
336 2016-11-18T16:14:23  *** abpa has quit IRC
337 2016-11-18T16:18:14  *** emzy has joined #bitcoin-core-dev
338 2016-11-18T16:20:13  *** Chris_Stewart_5 has quit IRC
339 2016-11-18T16:23:12  *** abpa has joined #bitcoin-core-dev
340 2016-11-18T16:26:22  *** JWU42 has left #bitcoin-core-dev
341 2016-11-18T16:27:10  *** abpa has quit IRC
342 2016-11-18T16:44:53  *** abpa has joined #bitcoin-core-dev
343 2016-11-18T16:45:41  *** abpa has quit IRC
344 2016-11-18T16:46:04  *** abpa has joined #bitcoin-core-dev
345 2016-11-18T17:10:41  *** rubensayshi has quit IRC
346 2016-11-18T17:13:27  <cfields> sipa: did i misunderstand your intention here? https://botbot.me/freenode/bitcoin-core-dev/2016-08-11/?msg=71172676&page=4
347 2016-11-18T17:15:16  <cfields> jl2012: those are likely ckpool, which will insert whenever it sees the rule
348 2016-11-18T17:17:49  <sipa> cfields: you did not misunderstand it.
349 2016-11-18T17:17:57  <sipa> but it's not what bitcoin core does
350 2016-11-18T17:18:11  <sipa> (which is irrelevant, as bitcoin core is not used for mining)
351 2016-11-18T17:18:52  <cfields> sipa: it inserts whenever it sees the rule. If it sees the rule and default_witness_commitment, it compares them to make sure that the computed value is sane
352 2016-11-18T17:19:42  <sipa> what is 'it'?
353 2016-11-18T17:19:47  <sipa> ah, ckpool
354 2016-11-18T17:20:16  <cfields> and cgminer, and the others I've done
355 2016-11-18T17:21:11  <cfields> For the simple stratum server, it only inserts default_witness_commitment if present
356 2016-11-18T17:25:19  *** grubles has quit IRC
357 2016-11-18T17:27:07  <BlueMatt> cfields: huh? I didnt read any comments you made as hostile? I think you needed sleep :p
358 2016-11-18T17:28:00  <cfields> BlueMatt: ok good
359 2016-11-18T17:31:31  *** grubles has joined #bitcoin-core-dev
360 2016-11-18T17:33:39  *** MykelSIlver has joined #bitcoin-core-dev
361 2016-11-18T17:53:16  *** grubles has quit IRC
362 2016-11-18T17:55:40  *** DigiByteDev has quit IRC
363 2016-11-18T18:01:28  *** grubles has joined #bitcoin-core-dev
364 2016-11-18T18:02:25  *** aalex__ has joined #bitcoin-core-dev
365 2016-11-18T18:06:04  *** aalex_ has quit IRC
366 2016-11-18T18:12:40  <sipa> cfields: i wonder if we could have a model where CNetMessage or whatever it is, is a virtual class that has an interface to produce a message on the fly
367 2016-11-18T18:13:13  <sipa> cfields: which could be used to delay loading a block from disk until it's actually going to be sent out through the network, for example
368 2016-11-18T18:13:47  <sipa> which could move the serialization of the checksum to the network thread as well
369 2016-11-18T18:14:50  <sipa> ah, but the checksum is in front, so it can only be donr after fully serializing
370 2016-11-18T18:16:44  *** Chris_Stewart_5 has joined #bitcoin-core-dev
371 2016-11-18T18:17:27  <cfields> sipa: the current approach just leaves padding upfront, so i don't think that breaks anything?
372 2016-11-18T18:20:09  <cfields> i'm not sure what you mean by "on-the-fly", though. You mean install a callback that triggers when a condition is met, then requests data to send out?
373 2016-11-18T18:22:11  <cfields> sipa: ah, i see. it just inserts a place-holder, and when that comes up for sending, it requests the actual data.
374 2016-11-18T18:26:28  <gmaxwell> cfields: I wish we always inserted the commitment when segwit rule is enabled. Without it, we may find the commitments fail after activation... not the end of the world, but more potential for delays.
375 2016-11-18T18:27:52  <cfields> gmaxwell: agreed
376 2016-11-18T18:29:13  *** jannes has quit IRC
377 2016-11-18T18:30:09  <cfields> it'd be helpful to setup a patched bitcoind that validates the commitments as though they were required, in the off-chance that we might notice a busted one before activation
378 2016-11-18T18:30:28  *** jtimon has joined #bitcoin-core-dev
379 2016-11-18T18:30:28  <cfields> i suppose it wouldn't actually be checking that much, but better than nothing
380 2016-11-18T18:42:05  *** aalex_ has joined #bitcoin-core-dev
381 2016-11-18T18:45:37  *** aalex__ has quit IRC
382 2016-11-18T18:52:36  <gmaxwell> Well we're due for a 0.13.2, we could put the commitment in by default when the rule is enabled.
383 2016-11-18T18:55:22  *** Chris_Stewart_5 has quit IRC
384 2016-11-18T18:56:53  *** Chris_Stewart_5 has joined #bitcoin-core-dev
385 2016-11-18T19:04:33  *** Chris_Stewart_5 has quit IRC
386 2016-11-18T19:06:11  *** Chris_Stewart_5 has joined #bitcoin-core-dev
387 2016-11-18T19:10:37  *** Chris_Stewart_5 has quit IRC
388 2016-11-18T19:17:13  <bitcoin-git> [bitcoin] gmaxwell opened pull request #9188: Make orphan parent fetching ask for witnesses. (master...witness_the_orphans) https://github.com/bitcoin/bitcoin/pull/9188
389 2016-11-18T19:18:37  <sipa> cfields: maybe in bip151 the checksum should be at the end
390 2016-11-18T19:18:46  <sipa> so it can be computee on the fly during sending
391 2016-11-18T19:19:08  <cfields> sipa: ack
392 2016-11-18T19:24:07  <luke-jr> gmaxwell: the commitment is inserted by the GBT client, not bitcoind
393 2016-11-18T19:27:13  *** Chris_Stewart_5 has joined #bitcoin-core-dev
394 2016-11-18T19:31:22  <gmaxwell> luke-jr: we make a proposed commitment that the client can use in lieu of implementing consensus rules when they don't need to (and thus won't put in the attention to do it right)
395 2016-11-18T19:33:25  <luke-jr> oh, I guess I didn't realise that wasn't unconditional
396 2016-11-18T19:33:52  <gmaxwell> for some reason it seems to be undocumented by any BIP. :( :(
397 2016-11-18T19:34:06  <gmaxwell> But nom, it only shows up when there are segwit txn right now. AFAIK.
398 2016-11-18T19:34:15  <sipa> right, default_witness_commitment is only added when there is an witness tx in the block
399 2016-11-18T19:34:19  <sipa> we can change that
400 2016-11-18T19:34:53  <luke-jr> yes, it's not in any BIP because it contradicts decentralised mining; it's a bitcoind-specific extension, not a GBT standard
401 2016-11-18T19:36:12  <sipa> it'll be a bitcoind-specific extension that the whole ecosystem depends on, because doing it in the client is pointless
402 2016-11-18T19:36:24  <gmaxwell> luke-jr: GBT as actually used contradicts decenteralized mining. We should fix decenteralized mining, not make a superficial stand that has a side effect of making the software more error prone.
403 2016-11-18T19:37:19  <gmaxwell> Because if you ask someone who _really_ doesn't care about the extra flexiblity there to handle computing the commitments themselves, they'll _hate it_ and be more likely to not implement it at all or to do so and get it wrong.
404 2016-11-18T19:37:41  <gmaxwell> Since they're getting the cost, but no one benefits because the end result doesn't improve mining decenteralization at all.
405 2016-11-18T19:38:40  <luke-jr> sipa: nobody uses it AFAIK
406 2016-11-18T19:39:12  <sipa> luke-jr: everyone uses it
407 2016-11-18T19:39:15  <sipa> cfields: right?
408 2016-11-18T19:39:27  <luke-jr> gmaxwell: it's not much more work than doing the txid merkle tree?
409 2016-11-18T19:39:58  <cfields> sipa: yea, it's upstreamed in several pools/miners now
410 2016-11-18T19:40:09  <luke-jr> cfields: ⁈
411 2016-11-18T19:40:15  <sipa> luke-jr: why redo the work when bitcoind already does it for you
412 2016-11-18T19:41:03  <cfields> luke-jr: the pools have enough things they could be breaking as-is. I don't see why we should pile more on
413 2016-11-18T19:41:27  <gmaxwell> luke-jr: It's similar to the merkle tree, but it is completely pointless when the software doesn't support changing the transaction set... and also not fast.
414 2016-11-18T19:42:56  <luke-jr> so why not just pass merkle branches in GBT too, if we're just going to throw the towel?
415 2016-11-18T19:43:29  <luke-jr> then we could have a BIP standard for centralised GBT that's complete
416 2016-11-18T19:43:48  <sipa> luke-jr: i think that is what we should do
417 2016-11-18T19:44:30  <sipa> not because i'm in favor of more centralization of mining, but because none of this matters at all
418 2016-11-18T19:44:38  <gmaxwell> It isn't necessarily centeralized though. e.g. phantomcircuit's unreleased protocol work does that and yet it's plausably much better for decenteralization than the deployment of GBT ever was in practice.
419 2016-11-18T19:44:43  *** brg444 has joined #bitcoin-core-dev
420 2016-11-18T19:44:43  <morcos> sipa: agreed..  there should at the very least be an option of doing it the easy simple way where bitcoind does all the hard work for you.
421 2016-11-18T19:45:17  <sipa> nothing is in a better position to do block composition than bitcoind... it has all the fee information, consensus rules, mempool data, ...
422 2016-11-18T19:45:37  <luke-jr> well, fee info is passed over GBT; but sure
423 2016-11-18T19:45:38  <sipa> if we want people to do their own composition, we should enable them to run bitcoind
424 2016-11-18T19:45:57  <sipa> not hope they'll do the same thing in a layer on top
425 2016-11-18T19:46:27  <gmaxwell> (phantomcircuits' work let you combine consensus from one source (e.g. your own bitcoind) with coinbase requests from another...)
426 2016-11-18T19:46:40  <morcos> well to be honest, in an ideal world there would be nothing to differentiate transactions other than their fee/weight , so no reason at all to need your own tx selection
427 2016-11-18T19:46:41  <luke-jr> so should I spend some time writing up a BIP for this? or is it just a low priority "maybe someday" thing?
428 2016-11-18T19:47:07  <sipa> luke-jr: i think we should first have a functional implementiation
429 2016-11-18T19:47:16  <luke-jr> morcos: disagree; but that may be all we end up having in practice perhaps
430 2016-11-18T19:47:59  <gmaxwell> We've had too much BIP writing without any code at all lately. IMO. Actually implementing something grants a lot of insight into the construction.
431 2016-11-18T19:48:59  <luke-jr> ok, but is there a desire to prioritise this?
432 2016-11-18T19:49:12  <sipa> luke-jr: in an ideal world, there exists no means for miners to even distinguish any properties of a transaction other than its size and fee... anything else is an avenue for censorship
433 2016-11-18T19:49:53  <sipa> luke-jr: i think the current situation with mining is pretty bad
434 2016-11-18T19:50:17  <gmaxwell> There are other serious problems with mining, the total lack of authentication is a looming serious risk to the network.
435 2016-11-18T19:50:34  <luke-jr> indeed
436 2016-11-18T19:50:39  <gmaxwell> Which, if exploited, we'd be saying in hindsight we were foolish to not resolve more agressively.
437 2016-11-18T19:50:51  <sipa> "hope is not a strategy"
438 2016-11-18T19:50:53  <cfields> luke-jr: i think this arose from the idea of having 0.13.2 always injecting segwit commitments if the rule is active. Hence, default_witness_commitment would always be available and we'd want it documented
439 2016-11-18T19:51:24  <sipa> i guess we can output default_witness_commitment always whenever the client is segwit-ready?
440 2016-11-18T19:52:18  <gmaxwell> I think we should.
441 2016-11-18T19:52:34  <luke-jr> sipa: IMO that's a "just do it" thing; should be simple and uncontroversial
442 2016-11-18T19:52:59  <luke-jr> looks like maybe 2 lines of changed code
443 2016-11-18T19:53:40  <gmaxwell> Yes, would need to be release noted as there is some fringe risk of negative interaction with mining pool software.
444 2016-11-18T19:53:47  <gmaxwell> But otherwise, I think it's a no-brainer.
445 2016-11-18T19:56:01  <luke-jr> actually, this might not be as simple as I assumed
446 2016-11-18T19:56:27  <luke-jr> nm
447 2016-11-18T19:56:30  <gmaxwell> hah
448 2016-11-18T19:56:53  <sipa> luke-jr: i'm on it, it's easy
449 2016-11-18T19:57:04  <luke-jr> what's the purpose of GetWitnessCommitmentIndex in GenerateCoinbaseCommitment?
450 2016-11-18T19:57:08  <luke-jr> sipa: ok
451 2016-11-18T19:57:59  <luke-jr> (that GetWitnessCommitmentIndex still looks pointless though?)
452 2016-11-18T19:58:44  <cfields> luke-jr: making sure there's not one there already, i think?
453 2016-11-18T19:58:49  <sipa> yup
454 2016-11-18T19:58:56  <luke-jr> cfields: but there never would be, in the one place it's called, no?
455 2016-11-18T19:59:47  <cfields> luke-jr: miner could've added it in
456 2016-11-18T19:59:52  <sipa> indeed
457 2016-11-18T20:00:20  <luke-jr> cfields: it's only called from CreateNewBlock
458 2016-11-18T20:00:31  <luke-jr> which is before the miner gets it
459 2016-11-18T20:01:19  <luke-jr> (I had assumed it was being used for the miner's submitted block as well, which would pose a risk to invalidating submissions without a commitment, but that doesn't appear to be the case)
460 2016-11-18T20:03:47  <cfields> luke-jr: dunno, maybe it was added before the mining side was fleshed out
461 2016-11-18T20:04:57  <luke-jr> probably
462 2016-11-18T20:05:16  <sipa> i believe so, yes
463 2016-11-18T20:06:11  <luke-jr> maybe it should be removed if it's dead code (in master, not 0.13.2)
464 2016-11-18T20:07:57  *** Chris_Stewart_5 has quit IRC
465 2016-11-18T20:21:29  *** Chris_Stewart_5 has joined #bitcoin-core-dev
466 2016-11-18T20:23:49  <bitcoin-git> [bitcoin] sipa opened pull request #9189: Always add default_witness_commitment with GBT client support (master...alwayscommit) https://github.com/bitcoin/bitcoin/pull/9189
467 2016-11-18T20:24:23  <sipa> ^ i ran the rpc tests and unit tests, but i haven't tested the behaviour
468 2016-11-18T20:28:16  <luke-jr> sipa: I don't think you need the additional check in GBT itself
469 2016-11-18T20:28:30  <luke-jr> if segwit is active, we fail earlier on if the client doesn't support it
470 2016-11-18T20:28:52  <sipa> luke-jr: yes, but there's no point producing a default_witness_commitment when the client doesn't understand it
471 2016-11-18T20:29:05  <sipa> i guess it doesn't really matter
472 2016-11-18T20:29:18  <luke-jr> there shouldn't be a commitment if the network doesn't have segwit active either, right?
473 2016-11-18T20:29:55  <sipa> the intent here is that there would be, whenever the client and the server support it
474 2016-11-18T20:30:08  <sipa> as it's a very nice end-to-end consistency check
475 2016-11-18T20:30:16  <sipa> to see that their entire stack works correctly
476 2016-11-18T20:31:05  <luke-jr> IMO it would be broken to insert a commitment (regardless of whether it's calculated) in a block without segwit being active on the network
477 2016-11-18T20:31:36  <sipa> arguably, it's just a weird OP_RETURN output in that case, and not actually a commitment
478 2016-11-18T20:31:43  <cfields> luke-jr: it's scary to count on all miners working 100% after activation
479 2016-11-18T20:32:02  <cfields> at least this way we get to see if someone thinks they should be ready but is horribly broken
480 2016-11-18T20:32:15  <luke-jr> if they add a commitment without "segwit" in "rules", there are already not working.
481 2016-11-18T20:32:20  <cfields> (since the only way they'd insert is if they're signaling that they're ready)
482 2016-11-18T20:32:47  <luke-jr> s/there/they/
483 2016-11-18T20:33:13  <gmaxwell> luke-jr: I disagree strongly. There is nothing wrong with a commitment that has no effect, and this means that the risk of a "hard cut" activation is reduced.
484 2016-11-18T20:33:32  <gmaxwell> Since if someone is producing broken commitments there is an oppturnity to go nag them to fix them, before the rule is enforced.
485 2016-11-18T20:33:50  <gmaxwell> I do think that there shouldn't be a commitment unless they have segwit in the rules, however.
486 2016-11-18T20:34:20  <sipa> gmaxwell: well if they don't support bip145, they will just ignore default_witness_commitment
487 2016-11-18T20:34:41  <luke-jr> sipa: even if they DO support BIP 145, they will ignore it..
488 2016-11-18T20:34:53  <gmaxwell> yes, but you might do something with the commitment but fail to realize that you need to send the rules. I guess it wouldn't be that bad an outcome: you'd just fail to mine segwit txn.
489 2016-11-18T20:34:57  <luke-jr> because "segwit" won't be in "rules" until it activates
490 2016-11-18T20:34:58  <sipa> luke-jr: i'd say they are allowed to ignore it
491 2016-11-18T20:35:14  <gmaxwell> yea, they're allowed to ignore it.
492 2016-11-18T20:35:16  <sipa> but they don't have to... there is nothing wrong with adding a commitment ahead of time
493 2016-11-18T20:35:25  <gmaxwell> Though I think it would be a good risk reduction if they didn't.
494 2016-11-18T20:36:02  *** meownow has joined #bitcoin-core-dev
495 2016-11-18T20:36:12  <luke-jr> I can't think of any downsides.
496 2016-11-18T20:36:24  <luke-jr> (to including it prematurely)
497 2016-11-18T20:37:26  <cfields> i suppose we have enough padding to ensure it doesn't push us over max size?
498 2016-11-18T20:37:37  <luke-jr> cfields: ?
499 2016-11-18T20:37:52  <sipa> cfields: if we have enough padding post activation, we certainly have enough before
500 2016-11-18T20:38:12  <luke-jr> block size padding is 1000 bytes. whether that's enough depends on the client
501 2016-11-18T20:38:27  <luke-jr> which is why Eloipool will modify the template in some circumstances I guess
502 2016-11-18T20:38:55  <cfields> sipa: i suppose that was a vague question aimed at both sides of activation
503 2016-11-18T20:38:58  <cfields> ok
504 2016-11-18T20:39:02  *** meownow_ has joined #bitcoin-core-dev
505 2016-11-18T20:39:17  <meownow_> anyone seen julian assange?
506 2016-11-18T20:39:25  <gmaxwell> luke-jr: refresh my memory, can the GBT client request a smaller template (e.g. because it knows its coinbase will be bigger)?
507 2016-11-18T20:39:36  <sipa> gmaxwell: not afaik
508 2016-11-18T20:40:02  <sipa> meownow_: off topic
509 2016-11-18T20:40:08  <gmaxwell> that should really be added.
510 2016-11-18T20:40:11  <luke-jr> gmaxwell: no, I don't think so. (either way, bitcoind doesn't support it)
511 2016-11-18T20:40:23  <luke-jr> probably
512 2016-11-18T20:40:26  *** meownow has quit IRC
513 2016-11-18T20:41:07  <luke-jr> maybe "sizelimit" as a request param, to override -blockmaxsize?
514 2016-11-18T20:41:19  <luke-jr> (and "weightlimit" the same)
515 2016-11-18T20:41:39  <sipa> or a parameter to communicate the coinbase size?
516 2016-11-18T20:41:54  <sipa> so the limit can still be set in bitcoind
517 2016-11-18T20:42:04  <luke-jr> hmm
518 2016-11-18T20:42:10  <gmaxwell> yea, coinbase size seems better.
519 2016-11-18T20:42:15  <gmaxwell> harder to screw up at least.
520 2016-11-18T20:42:47  <luke-jr> yes, the client in theory might not know the network max
521 2016-11-18T20:43:13  <sipa> the client in theory _shouldn't_ need to know the network max
522 2016-11-18T20:43:24  <luke-jr> "gentxsize" in the request then?
523 2016-11-18T20:43:26  <sipa> (though gbt pretty much forces the client to know consensus rule)
524 2016-11-18T20:43:42  <luke-jr> sipa: GBT provides the client with it, but only after the request
525 2016-11-18T20:43:45  <sdaftuar> weight, not size
526 2016-11-18T20:43:55  <luke-jr> sdaftuar: same thing basically in this case
527 2016-11-18T20:43:59  <sdaftuar> yes, but confusing
528 2016-11-18T20:44:41  <luke-jr> I'd find it less confusing to provide as size *shrug*
529 2016-11-18T20:45:06  <gmaxwell> cbmaxweight  "construct a template assuming that the coinbase transaction will have a weight no greater than x"
530 2016-11-18T21:03:34  *** aalex__ has joined #bitcoin-core-dev
531 2016-11-18T21:06:57  *** aalex_ has quit IRC
532 2016-11-18T21:32:52  *** Chris_Stewart_5 has quit IRC
533 2016-11-18T21:35:08  *** shesek has quit IRC
534 2016-11-18T21:35:10  *** jcorgan has quit IRC
535 2016-11-18T21:42:07  <jtimon> BlueMatt: so what's the next PR for the moveonly ?
536 2016-11-18T21:46:33  *** Chris_Stewart_5 has joined #bitcoin-core-dev
537 2016-11-18T21:49:06  *** shesek has joined #bitcoin-core-dev
538 2016-11-18T21:51:36  *** meownow_ has quit IRC
539 2016-11-18T21:54:28  *** cryptapus has quit IRC
540 2016-11-18T21:54:37  *** cryptapus has joined #bitcoin-core-dev
541 2016-11-18T21:54:37  *** cryptapus has joined #bitcoin-core-dev
542 2016-11-18T21:55:07  *** cryptapus is now known as cryptapus_afk
543 2016-11-18T22:04:52  *** Chris_Stewart_5 has quit IRC
544 2016-11-18T22:17:47  *** chjj has quit IRC
545 2016-11-18T22:20:32  *** Chris_Stewart_5 has joined #bitcoin-core-dev
546 2016-11-18T22:44:23  *** Guyver2 has quit IRC
547 2016-11-18T22:51:05  *** Chris_Stewart_5 has quit IRC
548 2016-11-18T23:07:38  *** Chris_Stewart_5 has joined #bitcoin-core-dev
549 2016-11-18T23:30:04  *** roidster has quit IRC
550 2016-11-18T23:57:11  *** abpa has quit IRC
551 2016-11-18T23:58:03  *** btcdrak has quit IRC
552 2016-11-18T23:59:01  <Lightsword> what’s the best way to compile 0.13.1 on debian 7? apparently doesn’t have full c++11 support