1 2016-11-18 00:04:15	0|sipa|BlueMatt: sure
  2 2016-11-18 00:04:36	0|gmaxwell|8ad0a328584b0be86df79c4335c043b0e3bbb2a380023fec55933f357b57edae
  3 2016-11-18 00:05:03	0|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-18 00:06:10	0|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-18 00:08:53	0|sipa|gmaxwell: ?
  6 2016-11-18 00:18:32	0|BlueMatt|sipa: ahh...well if its more of a patch I'm gonna skip it until you have it written
  7 2016-11-18 00:18:39	0|BlueMatt|and, maybe #9014 will be merged first :p
  8 2016-11-18 00:18:41	0|gribble|https://github.com/bitcoin/bitcoin/issues/9014 | Fix block-connection performance regression by TheBlueMatt · Pull Request #9014 · bitcoin/bitcoin · GitHub
  9 2016-11-18 00:37:36	0|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
 10 2016-11-18 00:37:44	0|sipa|through common subexpression elimination
 11 2016-11-18 00:46:49	0|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.
 12 2016-11-18 00:47:28	0|sipa|cfields: using multiple shared_ptr objects that refer to the same pointed-to object is threadsafe
 13 2016-11-18 00:47:41	0|sipa|cfields: using the same shared_ptr from multiple threads is not
 14 2016-11-18 00:51:08	0|jtimon|sipa: did you change 9125 or just rebase?
 15 2016-11-18 00:51:40	0|sipa|jtimon: both
 16 2016-11-18 00:51:52	0|sipa|jtimon: i'll comment on the changes
 17 2016-11-18 00:52:07	0|jtimon|cool, I tried https://github.com/sipa/bitcoin/compare/9bc6cbc4e24ef856ad4c803226378f276acc14ff...39e832c90012db03822f61009060712a47f7f81d but did work :p
 18 2016-11-18 00:53:10	0|cfields|sipa: got it, thanks
 19 2016-11-18 00:53:44	0|sipa|cfields: so as long as you're not creating/destroying/copying shared_ptr's, they are effectively identical to accessing a simple pointer
 20 2016-11-18 00:54:59	0|cfields|sipa: I see that now. I had a pretty fundamental misunderstanding about the overhead. That's very cool.
 21 2016-11-18 01:12:14	0|BlueMatt|cfields: see pm?
 22 2016-11-18 01:14:54	0|btcdrak|cfields: roasbeef said he's restarting those scripts
 23 2016-11-18 01:26:11	0|cfields|btcdrak: thanks
 24 2016-11-18 01:26:22	0|cfields|roasbeef: thanks too :)
 25 2016-11-18 02:09:53	0|sipa|jtimon: i was looking at it right now!
 26 2016-11-18 02:10:52	0|jtimon|sipa: cool, but you're the one who already looked at it :p it was for the others
 27 2016-11-18 02:11:19	0|jtimon|I mean, I'm definitely interested in kowing if the nits are solved
 28 2016-11-18 02:11:38	0|jtimon|knowing
 29 2016-11-18 02:20:33	0|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
 30 2016-11-18 02:26:52	0|sipa|roasbeef: they send MSG_TX getdatas instead of MSG_WITNESS_TX ?
 31 2016-11-18 02:27:12	0|roasbeef|sipa: yeh
 32 2016-11-18 02:27:26	0|chjj|sipa: yes. we have witness service bits, so do they. they repeatedly request our witness txs as non-witness.
 33 2016-11-18 02:27:27	0|roasbeef|the delayed reject is nonstd-script-verify due to empty witness
 34 2016-11-18 02:27:41	0|roasbeef|this then repeats as they aren't added to the reject cache
 35 2016-11-18 02:28:09	0|chjj|sipa: seems to be both 13.0 and 13.1 nodes
 36 2016-11-18 02:29:54	0|sipa|chjj, roasbeef: thanks, looking
 37 2016-11-18 02:30:27	0|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
 38 2016-11-18 02:31:27	0|sipa|found bug: getdatas of transactions sent in response to received transactions with missing inputs are always MSG_TX
 39 2016-11-18 02:31:57	0|roasbeef|ahh yeah he's generating  really long chain of multi-sigs
 40 2016-11-18 02:32:02	0|roasbeef|a really*
 41 2016-11-18 02:32:04	0|chjj|oh, haha
 42 2016-11-18 02:32:11	0|chjj|yeah, 3k nested transactions
 43 2016-11-18 02:32:53	0|chjj|yeah, that would do it. potential dos vector found i guess. i should spam the network more often. :)
 44 2016-11-18 02:33:17	0|sipa|thank you so much
 45 2016-11-18 02:34:31	0|gmaxwell|yea, thats an issue.
 46 2016-11-18 02:35:19	0|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.
 47 2016-11-18 02:35:32	0|gmaxwell|chjj, roasbeef thanks for finding that!!
 48 2016-11-18 02:36:05	0|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
 49 2016-11-18 02:36:06	0|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.
 50 2016-11-18 02:37:04	0|chjj|gmaxwell sipa: no problem. we were sitting here for the past hour dumbfounded. glad we figured it out here.
 51 2016-11-18 02:37:23	0|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
 52 2016-11-18 02:37:54	0|chjj|sipa: yeah, but it's a bunch of orphans. too-long-mempool-chain isn't checked for those i guess.
 53 2016-11-18 02:38:47	0|gmaxwell|yea, doesn't really check any of the consistency, orphan pool is mostly a big bag of transactions.
 54 2016-11-18 02:39:00	0|gmaxwell|And the 'fetch missing parents' is really just treating the orphan transaction like an implicit inv.
 55 2016-11-18 02:39:07	0|chjj|yeah
 56 2016-11-18 02:39:37	0|chjj|i was just signing a bunch of nested txs because roasbeef wanted me to. he wanted some big witness blocks. :)
 57 2016-11-18 02:39:50	0|roasbeef|yeh, I put him up to it ;)
 58 2016-11-18 02:39:51	0|chjj|wrote a script to endlessly sign and broadcast them
 59 2016-11-18 02:40:45	0|sipa|filed an issue
 60 2016-11-18 02:40:48	0|roasbeef|dope
 61 2016-11-18 03:28:20	0|bitcoin-git|[13bitcoin] 15TheBlueMatt reopened pull request #8930: Move orphan processing to ActivateBestChain (06master...06net_processing_3) 02https://github.com/bitcoin/bitcoin/pull/8930
 62 2016-11-18 03:29:24	0|BlueMatt|^ last pull before the final main.cpp split :)
 63 2016-11-18 03:29:46	0|BlueMatt|there are some minor fixes in the main.cpp split pull, but should be easy-ish to review
 64 2016-11-18 03:30:26	0|BlueMatt|and they seem to be getting smaller and smaller as we go :)
 65 2016-11-18 03:35:06	0|bitcoin-git|[13bitcoin] 15TheBlueMatt opened pull request #9183: Final Preparation for main.cpp Split (06master...06net_processing_5) 02https://github.com/bitcoin/bitcoin/pull/9183
 66 2016-11-18 03:38:57	0|crescendo|heh, glad I reconnected in time to see that one come across.  great work, @BlueMatt
 67 2016-11-18 03:39:26	0|sipa|BlueMatt: yay
 68 2016-11-18 04:47:40	0|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.
 69 2016-11-18 04:47:52	0|dermoth|Obviously there is no way to know about *all* destroyed coins, but there are obvious ways to destroy them which are factored in...
 70 2016-11-18 04:48:00	0|dermoth|Is there an official place to look for what should count as destroyed coins?
 71 2016-11-18 04:57:16	0|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.
 72 2016-11-18 05:30:15	0|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.
 73 2016-11-18 05:30:54	0|sipa|dermoth: i list some of them here http://bitcoin.stackexchange.com/questions/38994/will-there-be-21-million-bitcoins-eventually
 74 2016-11-18 05:31:23	0|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.)
 75 2016-11-18 05:31:34	0|midnightmagic|Is coin which never existed, actually destroyed?
 76 2016-11-18 05:34:03	0|midnightmagic|"Due to various bugs and miners experimenting with code, some blocks claim less than allowed."  <-- That is very kind of you sipa. :)
 77 2016-11-18 05:34:23	0|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.
 78 2016-11-18 05:34:29	0|sipa|^- that refers to you, i think
 79 2016-11-18 05:35:28	0|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.
 80 2016-11-18 05:35:39	0|midnightmagic|BlueMatt: thanks for the idea!
 81 2016-11-18 06:11:16	0|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...)
 82 2016-11-18 06:12:03	0|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.
 83 2016-11-18 06:12:51	0|sipa|dermoth: i think that's hopeless
 84 2016-11-18 06:13:20	0|sipa|there may be 100000s or millions of BTC lost due to destroyed/forgotten/... wallets
 85 2016-11-18 06:18:37	0|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
 86 2016-11-18 06:18:37	0|dermoth|s).
 87 2016-11-18 06:19:32	0|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
 88 2016-11-18 06:23:34	0|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.
 89 2016-11-18 06:27:02	0|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.
 90 2016-11-18 06:29:14	0|gmaxwell|sounds like a great reason to refuse to mine peoples' transactions near that boundary.
 91 2016-11-18 06:29:44	0|gmaxwell|You might want to assume less about what people have given thought to and haven't.
 92 2016-11-18 06:30:23	0|dermoth|well that is definitively a good point
 93 2016-11-18 06:30:34	0|rabidus|you would kill the "store of value" property of bitcoin
 94 2016-11-18 06:30:47	0|dermoth|and it wasn'T the reason given back then
 95 2016-11-18 06:30:48	0|rabidus|if i would need to move my voins from year to year just to ensure that i own them
 96 2016-11-18 06:32:06	0|dermoth|rabidus, what's wrong with that? but yeah, gmaxwell's point is quite an issue...
 97 2016-11-18 06:32:26	0|rabidus|if i might lose my coins just because i didn't move them, it is not very good store of value.
 98 2016-11-18 06:35:56	0|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
 99 2016-11-18 06:37:27	0|gmaxwell|"would be prioritized already" huh?
100 2016-11-18 06:37:33	0|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
101 2016-11-18 06:38:05	0|dermoth|tx that moves very old coins are prioritized aren't they?
102 2016-11-18 06:38:43	0|dermoth|priority = sum(input_value_in_base_units * input_age)/size_in_bytes
103 2016-11-18 06:38:59	0|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
104 2016-11-18 06:39:02	0|rabidus|oops, it's empty.
105 2016-11-18 06:39:39	0|dermoth|which - another think - I think tx with less outputs than inputs should be prioritized too, since they help reducing the utxo size
106 2016-11-18 06:40:37	0|dermoth|or to find that tour trezor's no longed functional, and your paper backup's ink washed out
107 2016-11-18 06:42:03	0|sipa|dermoth: there is only one rational prioritization rule, and that's fee per byte
108 2016-11-18 06:42:43	0|sipa|in the past, a few policies have existed that permitted old/larger coins, but they're no longer used by miners
109 2016-11-18 06:42:56	0|luke-jr|some miners still use them
110 2016-11-18 06:42:57	0|gmaxwell|jonasschnelli: the coin control gui sorts amounts lexographically!
111 2016-11-18 06:43:15	0|sipa|dermoth, rabidus: also, please take this to #bitcoin
112 2016-11-18 06:43:20	0|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?
113 2016-11-18 06:43:54	0|dermoth|yeah and my apologies; I though I was in #bitcoin-dev (not -core-)
114 2016-11-18 06:44:20	0|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
115 2016-11-18 06:44:38	0|sipa|dermoth: which segwit improves upon (but not enough, imo)
116 2016-11-18 06:47:57	0|luke-jr|or miners just decide to do the better thing
117 2016-11-18 06:51:24	0|sipa|luke-jr: we should build a system that incentivizes the right behaviour, not just hope for it
118 2016-11-18 06:51:26	0|jonasschnelli|gmaxwell: my CoinControl sorts it per value per default
119 2016-11-18 06:52:00	0|jonasschnelli|On which column do you have the "sort arrow"?
120 2016-11-18 06:52:24	0|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.
121 2016-11-18 06:54:20	0|jonasschnelli|gmaxwell: Qt persists the last sort order and column.
122 2016-11-18 06:54:28	0|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
123 2016-11-18 06:55:25	0|luke-jr|that would also be a protocol change.
124 2016-11-18 06:55:35	0|luke-jr|also, this isn't a matter of dependency
125 2016-11-18 06:56:03	0|luke-jr|the system doesn't fail if miners choose bad policies. it just works better if they choose good ones.
126 2016-11-18 06:56:38	0|luke-jr|and a better working system makes their bitcoins more valuable, so arguably it's already incentivised
127 2016-11-18 06:58:23	0|sipa|in the same way that a central bank is incentivised to not destroy a country's economy
128 2016-11-18 07:00:24	0|sipa|anyway, probably off topic here
129 2016-11-18 07:00:31	0|luke-jr|all incentives come down to value anyway
130 2016-11-18 07:01:41	0|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
131 2016-11-18 07:05:31	0|gmaxwell|jonasschnelli: if I click "amount" it swaps ascending and decending order, but the sort is not numeric.
132 2016-11-18 07:05:45	0|gmaxwell|e.g. it goes 1 10 2.
133 2016-11-18 07:06:11	0|jonasschnelli|gmaxwell: Ah.. I see your point...
134 2016-11-18 07:06:50	0|jonasschnelli|gmaxwell: strange... works on my end.
135 2016-11-18 07:07:00	0|gmaxwell|hm. qt difference perhaps?
136 2016-11-18 07:07:05	0|jonasschnelli|1 2.4 9 10 25
137 2016-11-18 07:07:17	0|jonasschnelli|I'm using Qt5.7
138 2016-11-18 07:07:22	0|jonasschnelli|Testing now on 5.6
139 2016-11-18 07:09:30	0|jonasschnelli|Also works with Qt5.6.1 (gitian)
140 2016-11-18 07:09:36	0|jonasschnelli|(OSX)
141 2016-11-18 07:11:18	0|gmaxwell|5.4.2 here. okay, well if it's just me then I won't worry about it!
142 2016-11-18 07:14:54	0|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.
143 2016-11-18 07:15:00	0|jonasschnelli|gmaxwell: Bug confirmed on Ubuntu with master built with gitian Qt5.6.1
144 2016-11-18 07:15:04	0|gmaxwell|\O/
145 2016-11-18 07:15:16	0|jonasschnelli|though... probably an upstream bug.
146 2016-11-18 07:15:32	0|wumpus|don't call it upstream bug too soon, qt is pretty good at sorting :p
147 2016-11-18 07:15:43	0|jonasschnelli|"probably"
148 2016-11-18 07:15:59	0|jonasschnelli|But the fact that its working on OSX and not on Ubuntu makes me think its very likely upstream
149 2016-11-18 07:16:04	0|gmaxwell|I should use the GUI more, it does a lot of things nicely.
150 2016-11-18 07:17:51	0|jonasschnelli|sortView(COLUMN_AMOUNT_INT64, Qt::DescendingOrder);
151 2016-11-18 07:18:18	0|wumpus|itemOutput->setText(COLUMN_AMOUNT_INT64, strPad(QString::number(out.tx->vout[out.i].nValue), 15, " ")); // padding so that sorting works correctly
152 2016-11-18 07:18:20	0|jonasschnelli|Ah... there is a hack involves.
153 2016-11-18 07:18:23	0|jonasschnelli|involved
154 2016-11-18 07:18:24	0|wumpus|eh ... :-(
155 2016-11-18 07:19:04	0|cfields|strPad(QString::number(out.tx->vout[out.i].nValue), 15, " ")); // padding so that sorting works correctly
156 2016-11-18 07:19:07	0|cfields|bah!
157 2016-11-18 07:19:09	0|cfields|beat me to it!
158 2016-11-18 07:19:37	0|wumpus|I somehow don't think that's the canonical way to do that
159 2016-11-18 07:19:42	0|jonasschnelli|Hey! Where is @Cozz...
160 2016-11-18 07:20:15	0|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
161 2016-11-18 07:20:29	0|wumpus|but yes I don't think any of us ever deeply looked at that code
162 2016-11-18 07:20:30	0|jonasschnelli|Yes.
163 2016-11-18 07:21:26	0|jonasschnelli|The hack was probably made because of the QTreeWidgetItem
164 2016-11-18 07:21:27	0|wumpus|it was not the prettiest code but works pretty well, generall
165 2016-11-18 07:21:36	0|jonasschnelli|Which maybe has some differences internally over a QTableView
166 2016-11-18 07:23:02	0|jonasschnelli|bool QTreeWidgetItem::operator<(const QTreeWidgetItem &other) const
167 2016-11-18 07:23:02	0|jonasschnelli|Qt code:
168 2016-11-18 07:23:06	0|jonasschnelli|return text(column) < other.text(column);
169 2016-11-18 07:23:08	0|jonasschnelli|:(
170 2016-11-18 07:26:29	0|wumpus|they can be subclassed though
171 2016-11-18 07:26:39	0|jonasschnelli|Yes. Trying to do that.
172 2016-11-18 07:26:46	0|jonasschnelli|But why is it working on OSX?
173 2016-11-18 07:27:26	0|wumpus|maybe some event handling difference, causing the hidden column not to be used for sorting?
174 2016-11-18 07:27:37	0|wumpus|either that or strPad(QString::number(out.tx->vout[out.i].nValue) returns something different on different OS but that soounds unlikely.
175 2016-11-18 07:28:42	0|Victorsueca|morning
176 2016-11-18 07:29:29	0|jonasschnelli|hi
177 2016-11-18 07:30:59	0|Victorsueca|how the hell does one remember so many Qt element calls?
178 2016-11-18 07:31:15	0|sipa|Victorsueca: google is your friend
179 2016-11-18 07:31:30	0|Victorsueca|yeah lol
180 2016-11-18 07:31:43	0|wumpus|use the search/grep/google whatever you prefer
181 2016-11-18 07:32:37	0|wumpus|you don't have to remember every detail, just where to find things when you need them
182 2016-11-18 07:33:11	0|sipa|exactly, you remember what things are possible, and how to use those
183 2016-11-18 07:33:33	0|sipa|you can always find the details of how to do them again later
184 2016-11-18 07:33:56	0|Victorsueca|yeah that's what I do with linux commands
185 2016-11-18 07:35:20	0|wumpus|jonasschnelli: most common suggestion seems indeed to be to override QTreeWidgetItem <
186 2016-11-18 07:36:22	0|Victorsueca|but when you're coding google not always brings the best way to do something for your specific case
187 2016-11-18 07:36:50	0|wumpus|oh sure there's still some skill involved
188 2016-11-18 07:38:55	0|wumpus|most important is that you're able to judge whether something is a good solution or not, so you can reject bad ones
189 2016-11-18 07:41:28	0|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
190 2016-11-18 07:47:16	0|Lauda|https://bitcoincore.org/en/segwit_adoption/ minor mistake here:"(note signalling will start around the 20th November 2016) "
191 2016-11-18 07:48:23	0|sipa|it'll start about an hour from now
192 2016-11-18 07:49:36	0|gmaxwell|Lauda: yea, that was the projection at the time the text was written.
193 2016-11-18 07:49:39	0|Lauda|Indeed. 8 blocks left
194 2016-11-18 07:52:14	0|jonasschnelli|wumpus: yes. Working on a fix. Though, it not to most important thing. :)
195 2016-11-18 08:00:29	0|btcdrak|Launda: thanks, will update
196 2016-11-18 08:19:21	0|Lauda|Good btcdrauk
197 2016-11-18 08:20:43	0|cfields|BlueMatt: maybe we should discuss approaches? Seems we might have something different in mind for encryption
198 2016-11-18 08:20:58	0|cfields|and sipa ^^
199 2016-11-18 08:24:46	0|BlueMatt|cfields: probably, but bedtime for me rn
200 2016-11-18 08:26:36	0|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.
201 2016-11-18 10:13:27	0|bitcoin-git|[13bitcoin] 15jonasschnelli opened pull request #9185: [Qt] fix coincontrol sort issue (06master...062016/11/fix_cc_sort) 02https://github.com/bitcoin/bitcoin/pull/9185
202 2016-11-18 12:13:43	0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #9186: test: Fix use-after-free in scheduler tests (06master...062016_11_scheduler_fix) 02https://github.com/bitcoin/bitcoin/pull/9186
203 2016-11-18 15:38:10	0|btcdrak|ping wumpus
204 2016-11-18 16:06:40	0|jl2012|blocks mined by a real 0.13.1 comes with a witness commitment: https://www.blocktrail.com/BTC/tx/86eb9975fae041df063f7ac0a94847883243704a7d20fb7726ba14239895a129
205 2016-11-18 16:07:21	0|jl2012|which is not found in slush's segwit blocks: https://www.blocktrail.com/BTC/tx/24dfb97c80d41e9dd153581b907c9270f8acd8509480e3bcde22684104d771c6
206 2016-11-18 16:08:16	0|sipa|jl2012: 0.13.1 only creates a commitment is there is a witness txn in the block, i believe
207 2016-11-18 16:08:52	0|jl2012|but there are already 2 blocks, from different miners, come with witness commitment
208 2016-11-18 16:09:28	0|sipa|it depends on their own stack, and arguably before activation there should certaibly not be a commitment
209 2016-11-18 16:09:38	0|jl2012|this one from an unknown miner: https://www.blocktrail.com/BTC/tx/c02b8e9c0321656a6ca429c3f38bed729b17347304aae9ce2b6454396621b1c1
210 2016-11-18 16:10:25	0|jl2012|not from BTCC: https://www.blocktrail.com/BTC/tx/5030f76f6411733458fa60fb706a9b2e0e7a3affd535004339482c42ec0a83d6
211 2016-11-18 17:13:27	0|cfields|sipa: did i misunderstand your intention here? https://botbot.me/freenode/bitcoin-core-dev/2016-08-11/?msg=71172676&page=4
212 2016-11-18 17:15:16	0|cfields|jl2012: those are likely ckpool, which will insert whenever it sees the rule
213 2016-11-18 17:17:49	0|sipa|cfields: you did not misunderstand it.
214 2016-11-18 17:17:57	0|sipa|but it's not what bitcoin core does
215 2016-11-18 17:18:12	0|sipa|(which is irrelevant, as bitcoin core is not used for mining)
216 2016-11-18 17:18:52	0|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
217 2016-11-18 17:19:42	0|sipa|what is 'it'?
218 2016-11-18 17:19:47	0|sipa|ah, ckpool
219 2016-11-18 17:20:16	0|cfields|and cgminer, and the others I've done
220 2016-11-18 17:21:11	0|cfields|For the simple stratum server, it only inserts default_witness_commitment if present
221 2016-11-18 17:27:08	0|BlueMatt|cfields: huh? I didnt read any comments you made as hostile? I think you needed sleep :p
222 2016-11-18 17:27:46	0|cfields|BlueMatt: ok good
223 2016-11-18 18:12:41	0|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
224 2016-11-18 18:13:13	0|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
225 2016-11-18 18:13:48	0|sipa|which could move the serialization of the checksum to the network thread as well
226 2016-11-18 18:14:51	0|sipa|ah, but the checksum is in front, so it can only be donr after fully serializing
227 2016-11-18 18:17:27	0|cfields|sipa: the current approach just leaves padding upfront, so i don't think that breaks anything?
228 2016-11-18 18:20:10	0|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?
229 2016-11-18 18:22:12	0|cfields|sipa: ah, i see. it just inserts a place-holder, and when that comes up for sending, it requests the actual data.
230 2016-11-18 18:26:29	0|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.
231 2016-11-18 18:27:53	0|cfields|gmaxwell: agreed
232 2016-11-18 18:30:10	0|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
233 2016-11-18 18:30:28	0|cfields|i suppose it wouldn't actually be checking that much, but better than nothing
234 2016-11-18 18:52:36	0|gmaxwell|Well we're due for a 0.13.2, we could put the commitment in by default when the rule is enabled.
235 2016-11-18 19:17:13	0|bitcoin-git|[13bitcoin] 15gmaxwell opened pull request #9188: Make orphan parent fetching ask for witnesses. (06master...06witness_the_orphans) 02https://github.com/bitcoin/bitcoin/pull/9188
236 2016-11-18 19:18:38	0|sipa|cfields: maybe in bip151 the checksum should be at the end
237 2016-11-18 19:18:47	0|sipa|so it can be computee on the fly during sending
238 2016-11-18 19:19:09	0|cfields|sipa: ack
239 2016-11-18 19:24:07	0|luke-jr|gmaxwell: the commitment is inserted by the GBT client, not bitcoind
240 2016-11-18 19:31:22	0|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)
241 2016-11-18 19:33:26	0|luke-jr|oh, I guess I didn't realise that wasn't unconditional
242 2016-11-18 19:33:53	0|gmaxwell|for some reason it seems to be undocumented by any BIP. :( :(
243 2016-11-18 19:34:06	0|gmaxwell|But nom, it only shows up when there are segwit txn right now. AFAIK.
244 2016-11-18 19:34:16	0|sipa|right, default_witness_commitment is only added when there is an witness tx in the block
245 2016-11-18 19:34:19	0|sipa|we can change that
246 2016-11-18 19:34:53	0|luke-jr|yes, it's not in any BIP because it contradicts decentralised mining; it's a bitcoind-specific extension, not a GBT standard
247 2016-11-18 19:36:13	0|sipa|it'll be a bitcoind-specific extension that the whole ecosystem depends on, because doing it in the client is pointless
248 2016-11-18 19:36:24	0|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.
249 2016-11-18 19:37:20	0|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.
250 2016-11-18 19:37:42	0|gmaxwell|Since they're getting the cost, but no one benefits because the end result doesn't improve mining decenteralization at all.
251 2016-11-18 19:38:40	0|luke-jr|sipa: nobody uses it AFAIK
252 2016-11-18 19:39:12	0|sipa|luke-jr: everyone uses it
253 2016-11-18 19:39:15	0|sipa|cfields: right?
254 2016-11-18 19:39:27	0|luke-jr|gmaxwell: it's not much more work than doing the txid merkle tree?
255 2016-11-18 19:39:58	0|cfields|sipa: yea, it's upstreamed in several pools/miners now
256 2016-11-18 19:40:10	0|luke-jr|cfields: ⁈
257 2016-11-18 19:40:16	0|sipa|luke-jr: why redo the work when bitcoind already does it for you
258 2016-11-18 19:41:04	0|cfields|luke-jr: the pools have enough things they could be breaking as-is. I don't see why we should pile more on
259 2016-11-18 19:41:27	0|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.
260 2016-11-18 19:42:56	0|luke-jr|so why not just pass merkle branches in GBT too, if we're just going to throw the towel?
261 2016-11-18 19:43:29	0|luke-jr|then we could have a BIP standard for centralised GBT that's complete
262 2016-11-18 19:43:48	0|sipa|luke-jr: i think that is what we should do
263 2016-11-18 19:44:30	0|sipa|not because i'm in favor of more centralization of mining, but because none of this matters at all
264 2016-11-18 19:44:38	0|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.
265 2016-11-18 19:44:43	0|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.
266 2016-11-18 19:45:18	0|sipa|nothing is in a better position to do block composition than bitcoind... it has all the fee information, consensus rules, mempool data, ...
267 2016-11-18 19:45:38	0|luke-jr|well, fee info is passed over GBT; but sure
268 2016-11-18 19:45:39	0|sipa|if we want people to do their own composition, we should enable them to run bitcoind
269 2016-11-18 19:45:57	0|sipa|not hope they'll do the same thing in a layer on top
270 2016-11-18 19:46:28	0|gmaxwell|(phantomcircuits' work let you combine consensus from one source (e.g. your own bitcoind) with coinbase requests from another...)
271 2016-11-18 19:46:40	0|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
272 2016-11-18 19:46:41	0|luke-jr|so should I spend some time writing up a BIP for this? or is it just a low priority "maybe someday" thing?
273 2016-11-18 19:47:08	0|sipa|luke-jr: i think we should first have a functional implementiation
274 2016-11-18 19:47:17	0|luke-jr|morcos: disagree; but that may be all we end up having in practice perhaps
275 2016-11-18 19:48:00	0|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.
276 2016-11-18 19:48:59	0|luke-jr|ok, but is there a desire to prioritise this?
277 2016-11-18 19:49:13	0|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
278 2016-11-18 19:49:53	0|sipa|luke-jr: i think the current situation with mining is pretty bad
279 2016-11-18 19:50:17	0|gmaxwell|There are other serious problems with mining, the total lack of authentication is a looming serious risk to the network.
280 2016-11-18 19:50:34	0|luke-jr|indeed
281 2016-11-18 19:50:39	0|gmaxwell|Which, if exploited, we'd be saying in hindsight we were foolish to not resolve more agressively.
282 2016-11-18 19:50:52	0|sipa|"hope is not a strategy"
283 2016-11-18 19:50:54	0|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
284 2016-11-18 19:51:24	0|sipa|i guess we can output default_witness_commitment always whenever the client is segwit-ready?
285 2016-11-18 19:52:19	0|gmaxwell|I think we should.
286 2016-11-18 19:52:35	0|luke-jr|sipa: IMO that's a "just do it" thing; should be simple and uncontroversial
287 2016-11-18 19:53:00	0|luke-jr|looks like maybe 2 lines of changed code
288 2016-11-18 19:53:40	0|gmaxwell|Yes, would need to be release noted as there is some fringe risk of negative interaction with mining pool software.
289 2016-11-18 19:53:47	0|gmaxwell|But otherwise, I think it's a no-brainer.
290 2016-11-18 19:56:01	0|luke-jr|actually, this might not be as simple as I assumed
291 2016-11-18 19:56:28	0|luke-jr|nm
292 2016-11-18 19:56:31	0|gmaxwell|hah
293 2016-11-18 19:56:54	0|sipa|luke-jr: i'm on it, it's easy
294 2016-11-18 19:57:05	0|luke-jr|what's the purpose of GetWitnessCommitmentIndex in GenerateCoinbaseCommitment?
295 2016-11-18 19:57:08	0|luke-jr|sipa: ok
296 2016-11-18 19:57:59	0|luke-jr|(that GetWitnessCommitmentIndex still looks pointless though?)
297 2016-11-18 19:58:44	0|cfields|luke-jr: making sure there's not one there already, i think?
298 2016-11-18 19:58:49	0|sipa|yup
299 2016-11-18 19:58:57	0|luke-jr|cfields: but there never would be, in the one place it's called, no?
300 2016-11-18 19:59:47	0|cfields|luke-jr: miner could've added it in
301 2016-11-18 19:59:53	0|sipa|indeed
302 2016-11-18 20:00:20	0|luke-jr|cfields: it's only called from CreateNewBlock
303 2016-11-18 20:00:31	0|luke-jr|which is before the miner gets it
304 2016-11-18 20:01:19	0|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)
305 2016-11-18 20:03:47	0|cfields|luke-jr: dunno, maybe it was added before the mining side was fleshed out
306 2016-11-18 20:04:58	0|luke-jr|probably
307 2016-11-18 20:05:17	0|sipa|i believe so, yes
308 2016-11-18 20:06:11	0|luke-jr|maybe it should be removed if it's dead code (in master, not 0.13.2)
309 2016-11-18 20:23:50	0|bitcoin-git|[13bitcoin] 15sipa opened pull request #9189: Always add default_witness_commitment with GBT client support (06master...06alwayscommit) 02https://github.com/bitcoin/bitcoin/pull/9189
310 2016-11-18 20:24:23	0|sipa|^ i ran the rpc tests and unit tests, but i haven't tested the behaviour
311 2016-11-18 20:28:17	0|luke-jr|sipa: I don't think you need the additional check in GBT itself
312 2016-11-18 20:28:30	0|luke-jr|if segwit is active, we fail earlier on if the client doesn't support it
313 2016-11-18 20:28:52	0|sipa|luke-jr: yes, but there's no point producing a default_witness_commitment when the client doesn't understand it
314 2016-11-18 20:29:05	0|sipa|i guess it doesn't really matter
315 2016-11-18 20:29:19	0|luke-jr|there shouldn't be a commitment if the network doesn't have segwit active either, right?
316 2016-11-18 20:29:56	0|sipa|the intent here is that there would be, whenever the client and the server support it
317 2016-11-18 20:30:08	0|sipa|as it's a very nice end-to-end consistency check
318 2016-11-18 20:30:17	0|sipa|to see that their entire stack works correctly
319 2016-11-18 20:31:05	0|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
320 2016-11-18 20:31:36	0|sipa|arguably, it's just a weird OP_RETURN output in that case, and not actually a commitment
321 2016-11-18 20:31:43	0|cfields|luke-jr: it's scary to count on all miners working 100% after activation
322 2016-11-18 20:32:02	0|cfields|at least this way we get to see if someone thinks they should be ready but is horribly broken
323 2016-11-18 20:32:15	0|luke-jr|if they add a commitment without "segwit" in "rules", there are already not working.
324 2016-11-18 20:32:21	0|cfields|(since the only way they'd insert is if they're signaling that they're ready)
325 2016-11-18 20:32:47	0|luke-jr|s/there/they/
326 2016-11-18 20:33:14	0|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.
327 2016-11-18 20:33:33	0|gmaxwell|Since if someone is producing broken commitments there is an oppturnity to go nag them to fix them, before the rule is enforced.
328 2016-11-18 20:33:50	0|gmaxwell|I do think that there shouldn't be a commitment unless they have segwit in the rules, however.
329 2016-11-18 20:34:20	0|sipa|gmaxwell: well if they don't support bip145, they will just ignore default_witness_commitment
330 2016-11-18 20:34:42	0|luke-jr|sipa: even if they DO support BIP 145, they will ignore it..
331 2016-11-18 20:34:53	0|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.
332 2016-11-18 20:34:58	0|luke-jr|because "segwit" won't be in "rules" until it activates
333 2016-11-18 20:34:59	0|sipa|luke-jr: i'd say they are allowed to ignore it
334 2016-11-18 20:35:14	0|gmaxwell|yea, they're allowed to ignore it.
335 2016-11-18 20:35:16	0|sipa|but they don't have to... there is nothing wrong with adding a commitment ahead of time
336 2016-11-18 20:35:25	0|gmaxwell|Though I think it would be a good risk reduction if they didn't.
337 2016-11-18 20:36:12	0|luke-jr|I can't think of any downsides.
338 2016-11-18 20:36:25	0|luke-jr|(to including it prematurely)
339 2016-11-18 20:37:26	0|cfields|i suppose we have enough padding to ensure it doesn't push us over max size?
340 2016-11-18 20:37:38	0|luke-jr|cfields: ?
341 2016-11-18 20:37:52	0|sipa|cfields: if we have enough padding post activation, we certainly have enough before
342 2016-11-18 20:38:12	0|luke-jr|block size padding is 1000 bytes. whether that's enough depends on the client
343 2016-11-18 20:38:27	0|luke-jr|which is why Eloipool will modify the template in some circumstances I guess
344 2016-11-18 20:38:55	0|cfields|sipa: i suppose that was a vague question aimed at both sides of activation
345 2016-11-18 20:38:58	0|cfields|ok
346 2016-11-18 20:39:18	0|meownow_|anyone seen julian assange?
347 2016-11-18 20:39:26	0|gmaxwell|luke-jr: refresh my memory, can the GBT client request a smaller template (e.g. because it knows its coinbase will be bigger)?
348 2016-11-18 20:39:36	0|sipa|gmaxwell: not afaik
349 2016-11-18 20:40:02	0|sipa|meownow_: off topic
350 2016-11-18 20:40:09	0|gmaxwell|that should really be added.
351 2016-11-18 20:40:11	0|luke-jr|gmaxwell: no, I don't think so. (either way, bitcoind doesn't support it)
352 2016-11-18 20:40:24	0|luke-jr|probably
353 2016-11-18 20:41:08	0|luke-jr|maybe "sizelimit" as a request param, to override -blockmaxsize?
354 2016-11-18 20:41:19	0|luke-jr|(and "weightlimit" the same)
355 2016-11-18 20:41:39	0|sipa|or a parameter to communicate the coinbase size?
356 2016-11-18 20:41:54	0|sipa|so the limit can still be set in bitcoind
357 2016-11-18 20:42:04	0|luke-jr|hmm
358 2016-11-18 20:42:10	0|gmaxwell|yea, coinbase size seems better.
359 2016-11-18 20:42:15	0|gmaxwell|harder to screw up at least.
360 2016-11-18 20:42:48	0|luke-jr|yes, the client in theory might not know the network max
361 2016-11-18 20:43:13	0|sipa|the client in theory _shouldn't_ need to know the network max
362 2016-11-18 20:43:24	0|luke-jr|"gentxsize" in the request then?
363 2016-11-18 20:43:27	0|sipa|(though gbt pretty much forces the client to know consensus rule)
364 2016-11-18 20:43:42	0|luke-jr|sipa: GBT provides the client with it, but only after the request
365 2016-11-18 20:43:46	0|sdaftuar|weight, not size
366 2016-11-18 20:43:56	0|luke-jr|sdaftuar: same thing basically in this case
367 2016-11-18 20:43:59	0|sdaftuar|yes, but confusing
368 2016-11-18 20:44:42	0|luke-jr|I'd find it less confusing to provide as size *shrug*
369 2016-11-18 20:45:06	0|gmaxwell|cbmaxweight  "construct a template assuming that the coinbase transaction will have a weight no greater than x"
370 2016-11-18 21:42:08	0|jtimon|BlueMatt: so what's the next PR for the moveonly ?
371 2016-11-18 23:59:02	0|Lightsword|what’s the best way to compile 0.13.1 on debian 7? apparently doesn’t have full c++11 support