12016-11-18T00:04:14 <sipa> BlueMatt: sure
22016-11-18T00:04:36 <gmaxwell> 8ad0a328584b0be86df79c4335c043b0e3bbb2a380023fec55933f357b57edae
32016-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')
42016-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
52016-11-18T00:08:52 <sipa> gmaxwell: ?
62016-11-18T00:13:37 *** Cory has quit IRC
72016-11-18T00:14:17 *** AdrianG has quit IRC
82016-11-18T00:14:17 *** jyap has quit IRC
92016-11-18T00:14:57 *** jyap has joined #bitcoin-core-dev
102016-11-18T00:14:58 *** jyap has joined #bitcoin-core-dev
112016-11-18T00:16:01 *** Pasha has joined #bitcoin-core-dev
122016-11-18T00:16:11 *** AdrianG has joined #bitcoin-core-dev
132016-11-18T00:18:32 <BlueMatt> sipa: ahh...well if its more of a patch I'm gonna skip it until you have it written
142016-11-18T00:18:38 <BlueMatt> and, maybe #9014 will be merged first :p
152016-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
162016-11-18T00:22:55 *** Pasha is now known as Cory
172016-11-18T00:36:15 *** laurentmt has joined #bitcoin-core-dev
182016-11-18T00:36:39 *** laurentmt has quit IRC
192016-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
202016-11-18T00:37:44 <sipa> through common subexpression elimination
212016-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.
222016-11-18T00:47:22 *** Chris_Stewart_5 has quit IRC
232016-11-18T00:47:28 <sipa> cfields: using multiple shared_ptr objects that refer to the same pointed-to object is threadsafe
242016-11-18T00:47:40 <sipa> cfields: using the same shared_ptr from multiple threads is not
252016-11-18T00:51:08 <jtimon> sipa: did you change 9125 or just rebase?
262016-11-18T00:51:39 <sipa> jtimon: both
272016-11-18T00:51:52 <sipa> jtimon: i'll comment on the changes
282016-11-18T00:52:06 <jtimon> cool, I tried https://github.com/sipa/bitcoin/compare/9bc6cbc4e24ef856ad4c803226378f276acc14ff...39e832c90012db03822f61009060712a47f7f81d but did work :p
292016-11-18T00:53:10 <cfields> sipa: got it, thanks
302016-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
312016-11-18T00:54:59 <cfields> sipa: I see that now. I had a pretty fundamental misunderstanding about the overhead. That's very cool.
322016-11-18T01:01:30 *** Chris_Stewart_5 has joined #bitcoin-core-dev
332016-11-18T01:12:13 <BlueMatt> cfields: see pm?
342016-11-18T01:14:53 <btcdrak> cfields: roasbeef said he's restarting those scripts
352016-11-18T01:15:34 *** Chris_Stewart_5 has quit IRC
362016-11-18T01:23:25 *** meownow has joined #bitcoin-core-dev
372016-11-18T01:26:10 <cfields> btcdrak: thanks
382016-11-18T01:26:22 <cfields> roasbeef: thanks too :)
392016-11-18T01:31:08 *** Chris_Stewart_5 has joined #bitcoin-core-dev
402016-11-18T01:45:57 *** Chris_Stewart_5 has quit IRC
412016-11-18T01:47:28 *** Chris_Stewart_5 has joined #bitcoin-core-dev
422016-11-18T01:56:44 *** abpa has quit IRC
432016-11-18T01:57:00 *** crescendo has quit IRC
442016-11-18T02:09:03 * jtimon re-asks for review on https://github.com/bitcoin/bitcoin/pull/8855
452016-11-18T02:09:53 <sipa> jtimon: i was looking at it right now!
462016-11-18T02:10:51 <jtimon> sipa: cool, but you're the one who already looked at it :p it was for the others
472016-11-18T02:11:19 <jtimon> I mean, I'm definitely interested in kowing if the nits are solved
482016-11-18T02:11:38 <jtimon> knowing
492016-11-18T02:16:48 *** chjj has joined #bitcoin-core-dev
502016-11-18T02:20:26 *** DigiByteDev has joined #bitcoin-core-dev
512016-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
522016-11-18T02:26:52 <sipa> roasbeef: they send MSG_TX getdatas instead of MSG_WITNESS_TX ?
532016-11-18T02:27:11 <roasbeef> sipa: yeh
542016-11-18T02:27:25 <chjj> sipa: yes. we have witness service bits, so do they. they repeatedly request our witness txs as non-witness.
552016-11-18T02:27:27 <roasbeef> the delayed reject is nonstd-script-verify due to empty witness
562016-11-18T02:27:40 <roasbeef> this then repeats as they aren't added to the reject cache
572016-11-18T02:28:09 <chjj> sipa: seems to be both 13.0 and 13.1 nodes
582016-11-18T02:29:54 <sipa> chjj, roasbeef: thanks, looking
592016-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
602016-11-18T02:31:26 <sipa> found bug: getdatas of transactions sent in response to received transactions with missing inputs are always MSG_TX
612016-11-18T02:31:57 <roasbeef> ahh yeah he's generating really long chain of multi-sigs
622016-11-18T02:32:01 <roasbeef> a really*
632016-11-18T02:32:03 <chjj> oh, haha
642016-11-18T02:32:11 <chjj> yeah, 3k nested transactions
652016-11-18T02:32:53 <chjj> yeah, that would do it. potential dos vector found i guess. i should spam the network more often. :)
662016-11-18T02:33:16 <sipa> thank you so much
672016-11-18T02:33:17 * roasbeef giggles
682016-11-18T02:34:31 <gmaxwell> yea, thats an issue.
692016-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.
702016-11-18T02:35:32 <gmaxwell> chjj, roasbeef thanks for finding that!!
712016-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
722016-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.
732016-11-18T02:37:03 <chjj> gmaxwell sipa: no problem. we were sitting here for the past hour dumbfounded. glad we figured it out here.
742016-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
752016-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.
762016-11-18T02:38:46 <gmaxwell> yea, doesn't really check any of the consistency, orphan pool is mostly a big bag of transactions.
772016-11-18T02:38:59 <gmaxwell> And the 'fetch missing parents' is really just treating the orphan transaction like an implicit inv.
782016-11-18T02:39:06 <chjj> yeah
792016-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. :)
802016-11-18T02:39:49 <roasbeef> yeh, I put him up to it ;)
812016-11-18T02:39:50 <chjj> wrote a script to endlessly sign and broadcast them
822016-11-18T02:40:44 <sipa> filed an issue
832016-11-18T02:40:48 <roasbeef> dope
842016-11-18T02:42:40 *** Giszmo has quit IRC
852016-11-18T02:57:24 *** To7 has joined #bitcoin-core-dev
862016-11-18T03:13:26 *** Alopex has quit IRC
872016-11-18T03:14:32 *** Alopex has joined #bitcoin-core-dev
882016-11-18T03:17:26 *** meownow has quit IRC
892016-11-18T03:27:10 *** abpa has joined #bitcoin-core-dev
902016-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
912016-11-18T03:29:23 <BlueMatt> ^ last pull before the final main.cpp split :)
922016-11-18T03:29:45 <BlueMatt> there are some minor fixes in the main.cpp split pull, but should be easy-ish to review
932016-11-18T03:30:11 *** crescendo has joined #bitcoin-core-dev
942016-11-18T03:30:25 <BlueMatt> and they seem to be getting smaller and smaller as we go :)
952016-11-18T03:31:25 *** Chris_Stewart_5 has quit IRC
962016-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
972016-11-18T03:38:57 <crescendo> heh, glad I reconnected in time to see that one come across. great work, @BlueMatt
982016-11-18T03:39:21 *** Squidicuz has quit IRC
992016-11-18T03:39:25 <sipa> BlueMatt: yay
1002016-11-18T03:44:32 *** Squidicuz has joined #bitcoin-core-dev
1012016-11-18T03:54:50 *** alpalp has joined #bitcoin-core-dev
1022016-11-18T03:54:50 *** DigiByteDev has quit IRC
1032016-11-18T04:10:48 *** alpalp has quit IRC
1042016-11-18T04:22:11 *** DigiByteDev has joined #bitcoin-core-dev
1052016-11-18T04:29:07 *** chjj has quit IRC
1062016-11-18T04:31:15 *** DigiByteDev has quit IRC
1072016-11-18T04:37:40 *** K4i7ok1d has joined #bitcoin-core-dev
1082016-11-18T04:43:00 *** dermoth has joined #bitcoin-core-dev
1092016-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.
1102016-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...
1112016-11-18T04:48:00 <dermoth> Is there an official place to look for what should count as destroyed coins?
1122016-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.
1132016-11-18T05:04:11 *** DigiByteDev has joined #bitcoin-core-dev
1142016-11-18T05:05:53 *** baldur has quit IRC
1152016-11-18T05:08:57 *** DigiByteDev has quit IRC
1162016-11-18T05:09:28 *** DigiByteDev has joined #bitcoin-core-dev
1172016-11-18T05:21:20 *** DigiByteDev has quit IRC
1182016-11-18T05:30:13 *** baldur has joined #bitcoin-core-dev
1192016-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.
1202016-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
1212016-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.)
1222016-11-18T05:31:34 <midnightmagic> Is coin which never existed, actually destroyed?
1232016-11-18T05:32:54 *** achow101 has joined #bitcoin-core-dev
1242016-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. :)
1252016-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.
1262016-11-18T05:34:28 <sipa> ^- that refers to you, i think
1272016-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.
1282016-11-18T05:35:38 <midnightmagic> BlueMatt: thanks for the idea!
1292016-11-18T05:35:40 * midnightmagic tips hat
1302016-11-18T05:49:20 *** bear13yte has joined #bitcoin-core-dev
1312016-11-18T05:59:31 *** bear13yte has quit IRC
1322016-11-18T06:00:41 *** wasi has quit IRC
1332016-11-18T06:01:07 *** Alopex has quit IRC
1342016-11-18T06:01:13 *** wasi has joined #bitcoin-core-dev
1352016-11-18T06:02:12 *** Alopex has joined #bitcoin-core-dev
1362016-11-18T06:11:03 *** JackH has quit IRC
1372016-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...)
1382016-11-18T06:11:28 *** JackH has joined #bitcoin-core-dev
1392016-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.
1402016-11-18T06:12:50 <sipa> dermoth: i think that's hopeless
1412016-11-18T06:13:19 <sipa> there may be 100000s or millions of BTC lost due to destroyed/forgotten/... wallets
1422016-11-18T06:13:52 *** DigiByteDev has joined #bitcoin-core-dev
1432016-11-18T06:18:23 *** jl2012 has quit IRC
1442016-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
1452016-11-18T06:18:36 <dermoth> s).
1462016-11-18T06:18:43 *** jl2012 has joined #bitcoin-core-dev
1472016-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
1482016-11-18T06:22:38 *** Ylbam has quit IRC
1492016-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.
1502016-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.
1512016-11-18T06:29:14 <gmaxwell> sounds like a great reason to refuse to mine peoples' transactions near that boundary.
1522016-11-18T06:29:43 <gmaxwell> You might want to assume less about what people have given thought to and haven't.
1532016-11-18T06:30:23 <dermoth> well that is definitively a good point
1542016-11-18T06:30:34 <rabidus> you would kill the "store of value" property of bitcoin
1552016-11-18T06:30:46 <dermoth> and it wasn'T the reason given back then
1562016-11-18T06:30:48 <rabidus> if i would need to move my voins from year to year just to ensure that i own them
1572016-11-18T06:32:05 <dermoth> rabidus, what's wrong with that? but yeah, gmaxwell's point is quite an issue...
1582016-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.
1592016-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
1602016-11-18T06:37:26 <gmaxwell> "would be prioritized already" huh?
1612016-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
1622016-11-18T06:38:04 <dermoth> tx that moves very old coins are prioritized aren't they?
1632016-11-18T06:38:42 <dermoth> priority = sum(input_value_in_base_units * input_age)/size_in_bytes
1642016-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
1652016-11-18T06:39:02 <rabidus> oops, it's empty.
1662016-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
1672016-11-18T06:40:37 <dermoth> or to find that tour trezor's no longed functional, and your paper backup's ink washed out
1682016-11-18T06:42:03 <sipa> dermoth: there is only one rational prioritization rule, and that's fee per byte
1692016-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
1702016-11-18T06:42:55 <luke-jr> some miners still use them
1712016-11-18T06:42:57 <gmaxwell> jonasschnelli: the coin control gui sorts amounts lexographically!
1722016-11-18T06:43:15 <sipa> dermoth, rabidus: also, please take this to #bitcoin
1732016-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?
1742016-11-18T06:43:50 * luke-jr thinks right now they sort by txid in that scenario
1752016-11-18T06:43:54 <dermoth> yeah and my apologies; I though I was in #bitcoin-dev (not -core-)
1762016-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
1772016-11-18T06:44:38 <sipa> dermoth: which segwit improves upon (but not enough, imo)
1782016-11-18T06:47:28 *** Alina-malina has quit IRC
1792016-11-18T06:47:28 *** Alina-malina has joined #bitcoin-core-dev
1802016-11-18T06:47:56 <luke-jr> or miners just decide to do the better thing
1812016-11-18T06:51:24 <sipa> luke-jr: we should build a system that incentivizes the right behaviour, not just hope for it
1822016-11-18T06:51:26 <jonasschnelli> gmaxwell: my CoinControl sorts it per value per default
1832016-11-18T06:52:00 <jonasschnelli> On which column do you have the "sort arrow"?
1842016-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.
1852016-11-18T06:54:19 <jonasschnelli> gmaxwell: Qt persists the last sort order and column.
1862016-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
1872016-11-18T06:55:25 <luke-jr> that would also be a protocol change.
1882016-11-18T06:55:35 <luke-jr> also, this isn't a matter of dependency
1892016-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.
1902016-11-18T06:56:38 <luke-jr> and a better working system makes their bitcoins more valuable, so arguably it's already incentivised
1912016-11-18T06:58:23 <sipa> in the same way that a central bank is incentivised to not destroy a country's economy
1922016-11-18T07:00:16 *** dermoth has quit IRC
1932016-11-18T07:00:24 <sipa> anyway, probably off topic here
1942016-11-18T07:00:30 <luke-jr> all incentives come down to value anyway
1952016-11-18T07:01:04 *** dermoth has joined #bitcoin-core-dev
1962016-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
1972016-11-18T07:05:30 <gmaxwell> jonasschnelli: if I click "amount" it swaps ascending and decending order, but the sort is not numeric.
1982016-11-18T07:05:45 <gmaxwell> e.g. it goes 1 10 2.
1992016-11-18T07:06:11 <jonasschnelli> gmaxwell: Ah.. I see your point...
2002016-11-18T07:06:50 <jonasschnelli> gmaxwell: strange... works on my end.
2012016-11-18T07:06:59 <gmaxwell> hm. qt difference perhaps?
2022016-11-18T07:07:05 <jonasschnelli> 1 2.4 9 10 25
2032016-11-18T07:07:17 <jonasschnelli> I'm using Qt5.7
2042016-11-18T07:07:22 <jonasschnelli> Testing now on 5.6
2052016-11-18T07:09:29 <jonasschnelli> Also works with Qt5.6.1 (gitian)
2062016-11-18T07:09:36 <jonasschnelli> (OSX)
2072016-11-18T07:11:18 <gmaxwell> 5.4.2 here. okay, well if it's just me then I won't worry about it!
2082016-11-18T07:11:42 * jonasschnelli booting up Ubuntu
2092016-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.
2102016-11-18T07:14:59 <jonasschnelli> gmaxwell: Bug confirmed on Ubuntu with master built with gitian Qt5.6.1
2112016-11-18T07:15:03 <gmaxwell> \O/
2122016-11-18T07:15:15 <jonasschnelli> though... probably an upstream bug.
2132016-11-18T07:15:32 <wumpus> don't call it upstream bug too soon, qt is pretty good at sorting :p
2142016-11-18T07:15:43 <jonasschnelli> "probably"
2152016-11-18T07:15:59 <jonasschnelli> But the fact that its working on OSX and not on Ubuntu makes me think its very likely upstream
2162016-11-18T07:16:03 <gmaxwell> I should use the GUI more, it does a lot of things nicely.
2172016-11-18T07:17:50 <jonasschnelli> sortView(COLUMN_AMOUNT_INT64, Qt::DescendingOrder);
2182016-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
2192016-11-18T07:18:20 <jonasschnelli> Ah... there is a hack involves.
2202016-11-18T07:18:23 <jonasschnelli> involved
2212016-11-18T07:18:23 <wumpus> eh ... :-(
2222016-11-18T07:19:03 <cfields> strPad(QString::number(out.tx->vout[out.i].nValue), 15, " ")); // padding so that sorting works correctly
2232016-11-18T07:19:06 <cfields> bah!
2242016-11-18T07:19:08 <cfields> beat me to it!
2252016-11-18T07:19:37 <wumpus> I somehow don't think that's the canonical way to do that
2262016-11-18T07:19:41 <jonasschnelli> Hey! Where is @Cozz...
2272016-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
2282016-11-18T07:20:28 <wumpus> but yes I don't think any of us ever deeply looked at that code
2292016-11-18T07:20:30 <jonasschnelli> Yes.
2302016-11-18T07:21:25 <jonasschnelli> The hack was probably made because of the QTreeWidgetItem
2312016-11-18T07:21:26 <wumpus> it was not the prettiest code but works pretty well, generall
2322016-11-18T07:21:36 <jonasschnelli> Which maybe has some differences internally over a QTableView
2332016-11-18T07:23:02 <jonasschnelli> Qt code:
2342016-11-18T07:23:02 <jonasschnelli> bool QTreeWidgetItem::operator<(const QTreeWidgetItem &other) const
2352016-11-18T07:23:06 <jonasschnelli> return text(column) < other.text(column);
2362016-11-18T07:23:07 <jonasschnelli> :(
2372016-11-18T07:26:28 <wumpus> they can be subclassed though
2382016-11-18T07:26:39 <jonasschnelli> Yes. Trying to do that.
2392016-11-18T07:26:46 <jonasschnelli> But why is it working on OSX?
2402016-11-18T07:27:25 <wumpus> maybe some event handling difference, causing the hidden column not to be used for sorting?
2412016-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.
2422016-11-18T07:28:29 * wumpus wonders why there's an inefficiently implemented strPad when Qt has a perfectly fine rightJustified() method on QString
2432016-11-18T07:28:41 <Victorsueca> morning
2442016-11-18T07:29:29 <jonasschnelli> hi
2452016-11-18T07:30:59 <Victorsueca> how the hell does one remember so many Qt element calls?
2462016-11-18T07:31:15 <sipa> Victorsueca: google is your friend
2472016-11-18T07:31:30 <Victorsueca> yeah lol
2482016-11-18T07:31:42 <wumpus> use the search/grep/google whatever you prefer
2492016-11-18T07:32:37 <wumpus> you don't have to remember every detail, just where to find things when you need them
2502016-11-18T07:33:11 <sipa> exactly, you remember what things are possible, and how to use those
2512016-11-18T07:33:33 <sipa> you can always find the details of how to do them again later
2522016-11-18T07:33:55 <Victorsueca> yeah that's what I do with linux commands
2532016-11-18T07:34:12 *** jtimon has quit IRC
2542016-11-18T07:35:20 <wumpus> jonasschnelli: most common suggestion seems indeed to be to override QTreeWidgetItem <
2552016-11-18T07:36:21 <Victorsueca> but when you're coding google not always brings the best way to do something for your specific case
2562016-11-18T07:36:50 <wumpus> oh sure there's still some skill involved
2572016-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
2582016-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
2592016-11-18T07:41:41 *** K4i7ok1d has quit IRC
2602016-11-18T07:41:53 *** jannes has joined #bitcoin-core-dev
2612016-11-18T07:46:58 *** Ylbam has joined #bitcoin-core-dev
2622016-11-18T07:47:15 <Lauda> https://bitcoincore.org/en/segwit_adoption/ minor mistake here:"(note signalling will start around the 20th November 2016) "
2632016-11-18T07:48:22 <sipa> it'll start about an hour from now
2642016-11-18T07:49:35 <gmaxwell> Lauda: yea, that was the projection at the time the text was written.
2652016-11-18T07:49:38 <Lauda> Indeed. 8 blocks left
2662016-11-18T07:52:13 <jonasschnelli> wumpus: yes. Working on a fix. Though, it not to most important thing. :)
2672016-11-18T08:00:29 <btcdrak> Launda: thanks, will update
2682016-11-18T08:14:54 *** roidster has quit IRC
2692016-11-18T08:19:21 <Lauda> Good btcdrauk
2702016-11-18T08:20:43 <cfields> BlueMatt: maybe we should discuss approaches? Seems we might have something different in mind for encryption
2712016-11-18T08:20:58 <cfields> and sipa ^^
2722016-11-18T08:24:27 *** DigiByteDev has quit IRC
2732016-11-18T08:24:45 <BlueMatt> cfields: probably, but bedtime for me rn
2742016-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.
2752016-11-18T08:28:02 *** rubensayshi has joined #bitcoin-core-dev
2762016-11-18T08:43:14 *** fanquake has joined #bitcoin-core-dev
2772016-11-18T09:18:38 *** Guyver2 has joined #bitcoin-core-dev
2782016-11-18T09:27:59 *** DigiByteDev has joined #bitcoin-core-dev
2792016-11-18T09:41:33 *** CubicEarth has joined #bitcoin-core-dev
2802016-11-18T09:43:23 *** windsok has quit IRC
2812016-11-18T09:47:24 *** ubuntu330 has joined #bitcoin-core-dev
2822016-11-18T09:50:29 *** ubuntu330 has quit IRC
2832016-11-18T09:55:35 *** gns3 has joined #bitcoin-core-dev
2842016-11-18T09:57:59 *** gielbier has joined #bitcoin-core-dev
2852016-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
2862016-11-18T10:15:23 *** windsok has joined #bitcoin-core-dev
2872016-11-18T10:20:51 *** molz has joined #bitcoin-core-dev
2882016-11-18T10:21:43 *** mol has joined #bitcoin-core-dev
2892016-11-18T10:23:10 *** moli has quit IRC
2902016-11-18T10:25:38 *** molz has quit IRC
2912016-11-18T10:59:29 *** laurentmt has joined #bitcoin-core-dev
2922016-11-18T10:59:44 *** laurentmt has quit IRC
2932016-11-18T11:16:15 *** DigiByteDev has quit IRC
2942016-11-18T11:17:33 *** DigiByteDev has joined #bitcoin-core-dev
2952016-11-18T11:18:58 *** CubicEarth has quit IRC
2962016-11-18T12:07:51 *** kadoban has quit IRC
2972016-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
2982016-11-18T12:46:37 *** Giszmo has joined #bitcoin-core-dev
2992016-11-18T13:04:30 *** fanquake has quit IRC
3002016-11-18T13:14:01 *** Alopex has quit IRC
3012016-11-18T13:15:07 *** Alopex has joined #bitcoin-core-dev
3022016-11-18T13:21:59 *** chris2000 has joined #bitcoin-core-dev
3032016-11-18T13:31:14 *** DigiByteDev has quit IRC
3042016-11-18T13:35:01 *** laurentmt has joined #bitcoin-core-dev
3052016-11-18T13:35:07 *** laurentmt has quit IRC
3062016-11-18T14:00:16 *** laurentmt has joined #bitcoin-core-dev
3072016-11-18T14:02:24 *** chris2000 has quit IRC
3082016-11-18T14:04:02 *** chjj has joined #bitcoin-core-dev
3092016-11-18T14:13:54 *** laurentmt1 has joined #bitcoin-core-dev
3102016-11-18T14:14:44 *** MarcoFalke has joined #bitcoin-core-dev
3112016-11-18T14:15:32 *** laurentmt has quit IRC
3122016-11-18T14:15:44 *** laurentmt1 is now known as laurentmt
3132016-11-18T14:25:15 *** cryptapus_afk has quit IRC
3142016-11-18T14:27:24 *** laurentmt has quit IRC
3152016-11-18T14:28:16 *** roidster has joined #bitcoin-core-dev
3162016-11-18T14:31:14 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3172016-11-18T14:49:53 *** DigiByteDev has joined #bitcoin-core-dev
3182016-11-18T15:04:23 *** Chris_Stewart_5 has quit IRC
3192016-11-18T15:07:55 *** paveljanik has quit IRC
3202016-11-18T15:13:09 *** cryptapus has joined #bitcoin-core-dev
3212016-11-18T15:13:10 *** cryptapus has joined #bitcoin-core-dev
3222016-11-18T15:19:58 *** Victorsueca has quit IRC
3232016-11-18T15:20:29 *** Victorsueca has joined #bitcoin-core-dev
3242016-11-18T15:20:43 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3252016-11-18T15:26:11 *** abpa has quit IRC
3262016-11-18T15:38:10 <btcdrak> ping wumpus
3272016-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
3282016-11-18T16:07:07 *** abpa has joined #bitcoin-core-dev
3292016-11-18T16:07:21 <jl2012> which is not found in slush's segwit blocks: https://www.blocktrail.com/BTC/tx/24dfb97c80d41e9dd153581b907c9270f8acd8509480e3bcde22684104d771c6
3302016-11-18T16:07:44 *** JWU42 has joined #bitcoin-core-dev
3312016-11-18T16:08:15 <sipa> jl2012: 0.13.1 only creates a commitment is there is a witness txn in the block, i believe
3322016-11-18T16:08:52 <jl2012> but there are already 2 blocks, from different miners, come with witness commitment
3332016-11-18T16:09:27 <sipa> it depends on their own stack, and arguably before activation there should certaibly not be a commitment
3342016-11-18T16:09:37 <jl2012> this one from an unknown miner: https://www.blocktrail.com/BTC/tx/c02b8e9c0321656a6ca429c3f38bed729b17347304aae9ce2b6454396621b1c1
3352016-11-18T16:10:25 <jl2012> not from BTCC: https://www.blocktrail.com/BTC/tx/5030f76f6411733458fa60fb706a9b2e0e7a3affd535004339482c42ec0a83d6
3362016-11-18T16:14:23 *** abpa has quit IRC
3372016-11-18T16:18:14 *** emzy has joined #bitcoin-core-dev
3382016-11-18T16:20:13 *** Chris_Stewart_5 has quit IRC
3392016-11-18T16:23:12 *** abpa has joined #bitcoin-core-dev
3402016-11-18T16:26:22 *** JWU42 has left #bitcoin-core-dev
3412016-11-18T16:27:10 *** abpa has quit IRC
3422016-11-18T16:44:53 *** abpa has joined #bitcoin-core-dev
3432016-11-18T16:45:41 *** abpa has quit IRC
3442016-11-18T16:46:04 *** abpa has joined #bitcoin-core-dev
3452016-11-18T17:10:41 *** rubensayshi has quit IRC
3462016-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
3472016-11-18T17:15:16 <cfields> jl2012: those are likely ckpool, which will insert whenever it sees the rule
3482016-11-18T17:17:49 <sipa> cfields: you did not misunderstand it.
3492016-11-18T17:17:57 <sipa> but it's not what bitcoin core does
3502016-11-18T17:18:11 <sipa> (which is irrelevant, as bitcoin core is not used for mining)
3512016-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
3522016-11-18T17:19:42 <sipa> what is 'it'?
3532016-11-18T17:19:47 <sipa> ah, ckpool
3542016-11-18T17:20:16 <cfields> and cgminer, and the others I've done
3552016-11-18T17:21:11 <cfields> For the simple stratum server, it only inserts default_witness_commitment if present
3562016-11-18T17:25:19 *** grubles has quit IRC
3572016-11-18T17:27:07 <BlueMatt> cfields: huh? I didnt read any comments you made as hostile? I think you needed sleep :p
3582016-11-18T17:28:00 <cfields> BlueMatt: ok good
3592016-11-18T17:31:31 *** grubles has joined #bitcoin-core-dev
3602016-11-18T17:33:39 *** MykelSIlver has joined #bitcoin-core-dev
3612016-11-18T17:53:16 *** grubles has quit IRC
3622016-11-18T17:55:40 *** DigiByteDev has quit IRC
3632016-11-18T18:01:28 *** grubles has joined #bitcoin-core-dev
3642016-11-18T18:02:25 *** aalex__ has joined #bitcoin-core-dev
3652016-11-18T18:06:04 *** aalex_ has quit IRC
3662016-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
3672016-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
3682016-11-18T18:13:47 <sipa> which could move the serialization of the checksum to the network thread as well
3692016-11-18T18:14:50 <sipa> ah, but the checksum is in front, so it can only be donr after fully serializing
3702016-11-18T18:16:44 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3712016-11-18T18:17:27 <cfields> sipa: the current approach just leaves padding upfront, so i don't think that breaks anything?
3722016-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?
3732016-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.
3742016-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.
3752016-11-18T18:27:52 <cfields> gmaxwell: agreed
3762016-11-18T18:29:13 *** jannes has quit IRC
3772016-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
3782016-11-18T18:30:28 *** jtimon has joined #bitcoin-core-dev
3792016-11-18T18:30:28 <cfields> i suppose it wouldn't actually be checking that much, but better than nothing
3802016-11-18T18:42:05 *** aalex_ has joined #bitcoin-core-dev
3812016-11-18T18:45:37 *** aalex__ has quit IRC
3822016-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.
3832016-11-18T18:55:22 *** Chris_Stewart_5 has quit IRC
3842016-11-18T18:56:53 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3852016-11-18T19:04:33 *** Chris_Stewart_5 has quit IRC
3862016-11-18T19:06:11 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3872016-11-18T19:10:37 *** Chris_Stewart_5 has quit IRC
3882016-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
3892016-11-18T19:18:37 <sipa> cfields: maybe in bip151 the checksum should be at the end
3902016-11-18T19:18:46 <sipa> so it can be computee on the fly during sending
3912016-11-18T19:19:08 <cfields> sipa: ack
3922016-11-18T19:24:07 <luke-jr> gmaxwell: the commitment is inserted by the GBT client, not bitcoind
3932016-11-18T19:27:13 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3942016-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)
3952016-11-18T19:33:25 <luke-jr> oh, I guess I didn't realise that wasn't unconditional
3962016-11-18T19:33:52 <gmaxwell> for some reason it seems to be undocumented by any BIP. :( :(
3972016-11-18T19:34:06 <gmaxwell> But nom, it only shows up when there are segwit txn right now. AFAIK.
3982016-11-18T19:34:15 <sipa> right, default_witness_commitment is only added when there is an witness tx in the block
3992016-11-18T19:34:19 <sipa> we can change that
4002016-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
4012016-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
4022016-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.
4032016-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.
4042016-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.
4052016-11-18T19:38:40 <luke-jr> sipa: nobody uses it AFAIK
4062016-11-18T19:39:12 <sipa> luke-jr: everyone uses it
4072016-11-18T19:39:15 <sipa> cfields: right?
4082016-11-18T19:39:27 <luke-jr> gmaxwell: it's not much more work than doing the txid merkle tree?
4092016-11-18T19:39:58 <cfields> sipa: yea, it's upstreamed in several pools/miners now
4102016-11-18T19:40:09 <luke-jr> cfields: â
4112016-11-18T19:40:15 <sipa> luke-jr: why redo the work when bitcoind already does it for you
4122016-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
4132016-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.
4142016-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?
4152016-11-18T19:43:29 <luke-jr> then we could have a BIP standard for centralised GBT that's complete
4162016-11-18T19:43:48 <sipa> luke-jr: i think that is what we should do
4172016-11-18T19:44:30 <sipa> not because i'm in favor of more centralization of mining, but because none of this matters at all
4182016-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.
4192016-11-18T19:44:43 *** brg444 has joined #bitcoin-core-dev
4202016-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.
4212016-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, ...
4222016-11-18T19:45:37 <luke-jr> well, fee info is passed over GBT; but sure
4232016-11-18T19:45:38 <sipa> if we want people to do their own composition, we should enable them to run bitcoind
4242016-11-18T19:45:57 <sipa> not hope they'll do the same thing in a layer on top
4252016-11-18T19:46:27 <gmaxwell> (phantomcircuits' work let you combine consensus from one source (e.g. your own bitcoind) with coinbase requests from another...)
4262016-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
4272016-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?
4282016-11-18T19:47:07 <sipa> luke-jr: i think we should first have a functional implementiation
4292016-11-18T19:47:16 <luke-jr> morcos: disagree; but that may be all we end up having in practice perhaps
4302016-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.
4312016-11-18T19:48:59 <luke-jr> ok, but is there a desire to prioritise this?
4322016-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
4332016-11-18T19:49:53 <sipa> luke-jr: i think the current situation with mining is pretty bad
4342016-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.
4352016-11-18T19:50:34 <luke-jr> indeed
4362016-11-18T19:50:39 <gmaxwell> Which, if exploited, we'd be saying in hindsight we were foolish to not resolve more agressively.
4372016-11-18T19:50:51 <sipa> "hope is not a strategy"
4382016-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
4392016-11-18T19:51:24 <sipa> i guess we can output default_witness_commitment always whenever the client is segwit-ready?
4402016-11-18T19:52:18 <gmaxwell> I think we should.
4412016-11-18T19:52:34 <luke-jr> sipa: IMO that's a "just do it" thing; should be simple and uncontroversial
4422016-11-18T19:52:59 <luke-jr> looks like maybe 2 lines of changed code
4432016-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.
4442016-11-18T19:53:47 <gmaxwell> But otherwise, I think it's a no-brainer.
4452016-11-18T19:56:01 <luke-jr> actually, this might not be as simple as I assumed
4462016-11-18T19:56:27 <luke-jr> nm
4472016-11-18T19:56:30 <gmaxwell> hah
4482016-11-18T19:56:53 <sipa> luke-jr: i'm on it, it's easy
4492016-11-18T19:57:04 <luke-jr> what's the purpose of GetWitnessCommitmentIndex in GenerateCoinbaseCommitment?
4502016-11-18T19:57:08 <luke-jr> sipa: ok
4512016-11-18T19:57:59 <luke-jr> (that GetWitnessCommitmentIndex still looks pointless though?)
4522016-11-18T19:58:44 <cfields> luke-jr: making sure there's not one there already, i think?
4532016-11-18T19:58:49 <sipa> yup
4542016-11-18T19:58:56 <luke-jr> cfields: but there never would be, in the one place it's called, no?
4552016-11-18T19:59:47 <cfields> luke-jr: miner could've added it in
4562016-11-18T19:59:52 <sipa> indeed
4572016-11-18T20:00:20 <luke-jr> cfields: it's only called from CreateNewBlock
4582016-11-18T20:00:31 <luke-jr> which is before the miner gets it
4592016-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)
4602016-11-18T20:03:47 <cfields> luke-jr: dunno, maybe it was added before the mining side was fleshed out
4612016-11-18T20:04:57 <luke-jr> probably
4622016-11-18T20:05:16 <sipa> i believe so, yes
4632016-11-18T20:06:11 <luke-jr> maybe it should be removed if it's dead code (in master, not 0.13.2)
4642016-11-18T20:07:57 *** Chris_Stewart_5 has quit IRC
4652016-11-18T20:21:29 *** Chris_Stewart_5 has joined #bitcoin-core-dev
4662016-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
4672016-11-18T20:24:23 <sipa> ^ i ran the rpc tests and unit tests, but i haven't tested the behaviour
4682016-11-18T20:28:16 <luke-jr> sipa: I don't think you need the additional check in GBT itself
4692016-11-18T20:28:30 <luke-jr> if segwit is active, we fail earlier on if the client doesn't support it
4702016-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
4712016-11-18T20:29:05 <sipa> i guess it doesn't really matter
4722016-11-18T20:29:18 <luke-jr> there shouldn't be a commitment if the network doesn't have segwit active either, right?
4732016-11-18T20:29:55 <sipa> the intent here is that there would be, whenever the client and the server support it
4742016-11-18T20:30:08 <sipa> as it's a very nice end-to-end consistency check
4752016-11-18T20:30:16 <sipa> to see that their entire stack works correctly
4762016-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
4772016-11-18T20:31:36 <sipa> arguably, it's just a weird OP_RETURN output in that case, and not actually a commitment
4782016-11-18T20:31:43 <cfields> luke-jr: it's scary to count on all miners working 100% after activation
4792016-11-18T20:32:02 <cfields> at least this way we get to see if someone thinks they should be ready but is horribly broken
4802016-11-18T20:32:15 <luke-jr> if they add a commitment without "segwit" in "rules", there are already not working.
4812016-11-18T20:32:20 <cfields> (since the only way they'd insert is if they're signaling that they're ready)
4822016-11-18T20:32:47 <luke-jr> s/there/they/
4832016-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.
4842016-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.
4852016-11-18T20:33:50 <gmaxwell> I do think that there shouldn't be a commitment unless they have segwit in the rules, however.
4862016-11-18T20:34:20 <sipa> gmaxwell: well if they don't support bip145, they will just ignore default_witness_commitment
4872016-11-18T20:34:41 <luke-jr> sipa: even if they DO support BIP 145, they will ignore it..
4882016-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.
4892016-11-18T20:34:57 <luke-jr> because "segwit" won't be in "rules" until it activates
4902016-11-18T20:34:58 <sipa> luke-jr: i'd say they are allowed to ignore it
4912016-11-18T20:35:14 <gmaxwell> yea, they're allowed to ignore it.
4922016-11-18T20:35:16 <sipa> but they don't have to... there is nothing wrong with adding a commitment ahead of time
4932016-11-18T20:35:25 <gmaxwell> Though I think it would be a good risk reduction if they didn't.
4942016-11-18T20:36:02 *** meownow has joined #bitcoin-core-dev
4952016-11-18T20:36:12 <luke-jr> I can't think of any downsides.
4962016-11-18T20:36:24 <luke-jr> (to including it prematurely)
4972016-11-18T20:37:26 <cfields> i suppose we have enough padding to ensure it doesn't push us over max size?
4982016-11-18T20:37:37 <luke-jr> cfields: ?
4992016-11-18T20:37:52 <sipa> cfields: if we have enough padding post activation, we certainly have enough before
5002016-11-18T20:38:12 <luke-jr> block size padding is 1000 bytes. whether that's enough depends on the client
5012016-11-18T20:38:27 <luke-jr> which is why Eloipool will modify the template in some circumstances I guess
5022016-11-18T20:38:55 <cfields> sipa: i suppose that was a vague question aimed at both sides of activation
5032016-11-18T20:38:58 <cfields> ok
5042016-11-18T20:39:02 *** meownow_ has joined #bitcoin-core-dev
5052016-11-18T20:39:17 <meownow_> anyone seen julian assange?
5062016-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)?
5072016-11-18T20:39:36 <sipa> gmaxwell: not afaik
5082016-11-18T20:40:02 <sipa> meownow_: off topic
5092016-11-18T20:40:08 <gmaxwell> that should really be added.
5102016-11-18T20:40:11 <luke-jr> gmaxwell: no, I don't think so. (either way, bitcoind doesn't support it)
5112016-11-18T20:40:23 <luke-jr> probably
5122016-11-18T20:40:26 *** meownow has quit IRC
5132016-11-18T20:41:07 <luke-jr> maybe "sizelimit" as a request param, to override -blockmaxsize?
5142016-11-18T20:41:19 <luke-jr> (and "weightlimit" the same)
5152016-11-18T20:41:39 <sipa> or a parameter to communicate the coinbase size?
5162016-11-18T20:41:54 <sipa> so the limit can still be set in bitcoind
5172016-11-18T20:42:04 <luke-jr> hmm
5182016-11-18T20:42:10 <gmaxwell> yea, coinbase size seems better.
5192016-11-18T20:42:15 <gmaxwell> harder to screw up at least.
5202016-11-18T20:42:47 <luke-jr> yes, the client in theory might not know the network max
5212016-11-18T20:43:13 <sipa> the client in theory _shouldn't_ need to know the network max
5222016-11-18T20:43:24 <luke-jr> "gentxsize" in the request then?
5232016-11-18T20:43:26 <sipa> (though gbt pretty much forces the client to know consensus rule)
5242016-11-18T20:43:42 <luke-jr> sipa: GBT provides the client with it, but only after the request
5252016-11-18T20:43:45 <sdaftuar> weight, not size
5262016-11-18T20:43:55 <luke-jr> sdaftuar: same thing basically in this case
5272016-11-18T20:43:59 <sdaftuar> yes, but confusing
5282016-11-18T20:44:41 <luke-jr> I'd find it less confusing to provide as size *shrug*
5292016-11-18T20:45:06 <gmaxwell> cbmaxweight "construct a template assuming that the coinbase transaction will have a weight no greater than x"
5302016-11-18T21:03:34 *** aalex__ has joined #bitcoin-core-dev
5312016-11-18T21:06:57 *** aalex_ has quit IRC
5322016-11-18T21:32:52 *** Chris_Stewart_5 has quit IRC
5332016-11-18T21:35:08 *** shesek has quit IRC
5342016-11-18T21:35:10 *** jcorgan has quit IRC
5352016-11-18T21:42:07 <jtimon> BlueMatt: so what's the next PR for the moveonly ?
5362016-11-18T21:46:33 *** Chris_Stewart_5 has joined #bitcoin-core-dev
5372016-11-18T21:49:06 *** shesek has joined #bitcoin-core-dev
5382016-11-18T21:51:36 *** meownow_ has quit IRC
5392016-11-18T21:54:28 *** cryptapus has quit IRC
5402016-11-18T21:54:37 *** cryptapus has joined #bitcoin-core-dev
5412016-11-18T21:54:37 *** cryptapus has joined #bitcoin-core-dev
5422016-11-18T21:55:07 *** cryptapus is now known as cryptapus_afk
5432016-11-18T22:04:52 *** Chris_Stewart_5 has quit IRC
5442016-11-18T22:17:47 *** chjj has quit IRC
5452016-11-18T22:20:32 *** Chris_Stewart_5 has joined #bitcoin-core-dev
5462016-11-18T22:44:23 *** Guyver2 has quit IRC
5472016-11-18T22:51:05 *** Chris_Stewart_5 has quit IRC
5482016-11-18T23:07:38 *** Chris_Stewart_5 has joined #bitcoin-core-dev
5492016-11-18T23:30:04 *** roidster has quit IRC
5502016-11-18T23:57:11 *** abpa has quit IRC
5512016-11-18T23:58:03 *** btcdrak has quit IRC
5522016-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