12018-11-28T00:06:15  *** promag has quit IRC
  22018-11-28T00:10:11  *** shesek has quit IRC
  32018-11-28T00:10:40  *** shesek has joined #bitcoin-core-dev
  42018-11-28T00:24:52  *** spinza has quit IRC
  52018-11-28T00:27:29  *** shesek has quit IRC
  62018-11-28T00:27:56  *** twistedline_ has joined #bitcoin-core-dev
  72018-11-28T00:28:30  *** shesek has joined #bitcoin-core-dev
  82018-11-28T00:28:32  *** twistedline has quit IRC
  92018-11-28T00:32:09  *** spinza has joined #bitcoin-core-dev
 102018-11-28T00:42:20  *** shesek has quit IRC
 112018-11-28T00:43:05  *** shesek has joined #bitcoin-core-dev
 122018-11-28T00:49:16  *** shesek has quit IRC
 132018-11-28T00:49:54  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 142018-11-28T00:49:56  *** shesek has joined #bitcoin-core-dev
 152018-11-28T00:49:56  *** shesek has joined #bitcoin-core-dev
 162018-11-28T00:53:34  *** shesek has quit IRC
 172018-11-28T00:54:01  *** shesek has joined #bitcoin-core-dev
 182018-11-28T00:54:01  *** shesek has joined #bitcoin-core-dev
 192018-11-28T01:02:31  *** phwalkr has quit IRC
 202018-11-28T01:03:05  *** phwalkr has joined #bitcoin-core-dev
 212018-11-28T01:06:11  *** zallarak has quit IRC
 222018-11-28T01:07:13  *** phwalkr has quit IRC
 232018-11-28T01:11:15  *** jb55 has joined #bitcoin-core-dev
 242018-11-28T01:11:56  *** Alan_W has joined #bitcoin-core-dev
 252018-11-28T01:14:27  *** shesek has quit IRC
 262018-11-28T01:15:18  *** shesek has joined #bitcoin-core-dev
 272018-11-28T01:33:41  *** shesek has quit IRC
 282018-11-28T01:34:31  *** shesek has joined #bitcoin-core-dev
 292018-11-28T01:44:31  *** shesek has quit IRC
 302018-11-28T01:46:05  *** shesek has joined #bitcoin-core-dev
 312018-11-28T01:46:05  *** shesek has joined #bitcoin-core-dev
 322018-11-28T01:50:03  *** andytoshi has quit IRC
 332018-11-28T02:01:28  *** Chris_Stewart_5 has quit IRC
 342018-11-28T02:05:20  *** Murch has quit IRC
 352018-11-28T02:06:09  *** Murch has joined #bitcoin-core-dev
 362018-11-28T02:07:41  *** Murch has quit IRC
 372018-11-28T02:12:57  *** Alan_W has quit IRC
 382018-11-28T02:17:06  *** zivl has quit IRC
 392018-11-28T02:20:57  *** shesek has quit IRC
 402018-11-28T02:21:31  *** shesek has joined #bitcoin-core-dev
 412018-11-28T02:21:59  *** shesek has quit IRC
 422018-11-28T02:23:05  *** shesek has joined #bitcoin-core-dev
 432018-11-28T02:24:30  *** Victorsueca has quit IRC
 442018-11-28T02:25:40  *** Victorsueca has joined #bitcoin-core-dev
 452018-11-28T02:27:05  *** shesek has quit IRC
 462018-11-28T02:28:32  *** shesek has joined #bitcoin-core-dev
 472018-11-28T02:41:22  *** shesek has quit IRC
 482018-11-28T02:42:10  *** shesek has joined #bitcoin-core-dev
 492018-11-28T02:42:10  *** shesek has joined #bitcoin-core-dev
 502018-11-28T02:55:35  *** _cryptodesktop_i has joined #bitcoin-core-dev
 512018-11-28T02:59:09  *** shesek has quit IRC
 522018-11-28T03:03:06  *** shesek has joined #bitcoin-core-dev
 532018-11-28T03:10:16  *** shesek has quit IRC
 542018-11-28T03:10:56  *** shesek has joined #bitcoin-core-dev
 552018-11-28T03:10:56  *** shesek has joined #bitcoin-core-dev
 562018-11-28T03:13:23  *** qwe has joined #bitcoin-core-dev
 572018-11-28T03:13:28  <qwe> .
 582018-11-28T03:13:33  <qwe> hello
 592018-11-28T03:14:03  *** qwe has quit IRC
 602018-11-28T03:14:04  *** shesek has quit IRC
 612018-11-28T03:16:31  *** wxss has quit IRC
 622018-11-28T03:16:41  *** shesek has joined #bitcoin-core-dev
 632018-11-28T03:16:41  *** shesek has joined #bitcoin-core-dev
 642018-11-28T03:18:48  *** AaronvanW has quit IRC
 652018-11-28T03:29:26  *** _cryptodesktop_i has quit IRC
 662018-11-28T03:40:58  *** shesek has quit IRC
 672018-11-28T03:42:01  *** rh0nj has quit IRC
 682018-11-28T03:42:03  *** shesek has joined #bitcoin-core-dev
 692018-11-28T03:45:07  *** rh0nj has joined #bitcoin-core-dev
 702018-11-28T03:45:22  *** shesek has quit IRC
 712018-11-28T03:46:38  *** shesek has joined #bitcoin-core-dev
 722018-11-28T03:54:39  *** andytoshi has joined #bitcoin-core-dev
 732018-11-28T04:10:39  *** indistylo has joined #bitcoin-core-dev
 742018-11-28T04:13:02  *** schnerchi has joined #bitcoin-core-dev
 752018-11-28T04:15:48  *** schnerch_ has quit IRC
 762018-11-28T04:16:49  *** owowo has quit IRC
 772018-11-28T04:22:24  *** owowo has joined #bitcoin-core-dev
 782018-11-28T04:34:42  *** indistylo has quit IRC
 792018-11-28T04:43:50  *** grubles_ has joined #bitcoin-core-dev
 802018-11-28T04:45:48  *** grubles has quit IRC
 812018-11-28T04:54:23  *** shesek has quit IRC
 822018-11-28T04:55:50  *** shesek has joined #bitcoin-core-dev
 832018-11-28T05:09:55  *** shesek has quit IRC
 842018-11-28T05:12:19  *** indistylo has joined #bitcoin-core-dev
 852018-11-28T05:12:21  *** shesek has joined #bitcoin-core-dev
 862018-11-28T05:14:56  *** murph11 has joined #bitcoin-core-dev
 872018-11-28T05:15:13  *** grubles_ is now known as grubles
 882018-11-28T05:28:21  *** shesek has quit IRC
 892018-11-28T05:29:26  *** shesek has joined #bitcoin-core-dev
 902018-11-28T05:29:26  *** shesek has joined #bitcoin-core-dev
 912018-11-28T05:31:25  *** shesek has quit IRC
 922018-11-28T05:31:55  *** shesek has joined #bitcoin-core-dev
 932018-11-28T05:40:38  *** wolfspraul has quit IRC
 942018-11-28T05:43:20  *** indistylo has quit IRC
 952018-11-28T05:45:00  *** drexl has quit IRC
 962018-11-28T05:49:02  *** shesek has quit IRC
 972018-11-28T05:50:10  *** shesek has joined #bitcoin-core-dev
 982018-11-28T05:55:52  *** shesek has quit IRC
 992018-11-28T05:57:55  *** shesek has joined #bitcoin-core-dev
1002018-11-28T05:58:36  *** shesek has quit IRC
1012018-11-28T05:59:45  *** shesek has joined #bitcoin-core-dev
1022018-11-28T06:13:20  *** shesek has quit IRC
1032018-11-28T06:13:45  *** shesek has joined #bitcoin-core-dev
1042018-11-28T06:15:55  <meshcollider> sipa: in your GetAffectedKeys PR, it will always return the pubkey in the case of P2PK or similar won't it
1052018-11-28T06:16:29  <meshcollider> Even if it's not in the wallet
1062018-11-28T06:20:24  <meshcollider> I guess thats ok actually
1072018-11-28T06:26:52  <sipa> yes
1082018-11-28T06:27:36  *** shesek has quit IRC
1092018-11-28T06:29:29  *** shesek has joined #bitcoin-core-dev
1102018-11-28T06:38:09  *** grubles has quit IRC
1112018-11-28T06:38:37  *** grubles has joined #bitcoin-core-dev
1122018-11-28T06:38:41  *** grubles has quit IRC
1132018-11-28T06:40:36  *** dviola has quit IRC
1142018-11-28T06:43:39  *** shesek has quit IRC
1152018-11-28T06:45:19  *** shesek has joined #bitcoin-core-dev
1162018-11-28T06:45:35  *** shesek has joined #bitcoin-core-dev
1172018-11-28T06:45:41  *** shesek has quit IRC
1182018-11-28T06:46:40  *** NicolasDorier has joined #bitcoin-core-dev
1192018-11-28T06:47:22  <NicolasDorier> Hi everybody. I am trying to find a user friendly way to share a UTXO set with raspberry pi of non technical users.
1202018-11-28T06:47:46  <NicolasDorier> At first I was thinking to do https://github.com/bitcoin/bitcoin/pull/13713#issuecomment-442333282
1212018-11-28T06:48:15  <NicolasDorier> however this seems complicated, and not possible today
1222018-11-28T06:49:07  <sipa> there was a PR for adding a dump utxo set to the rest interface
1232018-11-28T06:49:31  <sipa> but it required a non-released libevent or so
1242018-11-28T06:49:41  <NicolasDorier> so instead I was thinking the following: What about Bitcoin Core share the txoutset hash on bitcoincore website or twitter or whatever (like every 1000 blocks). At BTCPay level, I would show the UTXOSet of their own node and check against the website
1252018-11-28T06:49:45  *** shesek has joined #bitcoin-core-dev
1262018-11-28T06:49:45  *** shesek has joined #bitcoin-core-dev
1272018-11-28T06:49:48  <NicolasDorier> and display a warning if that differ
1282018-11-28T06:50:26  <NicolasDorier> So the user could fast sync from untrusted source, and would get a warning if that differ from Bitcoin Core website/twitter or whatever publish mechanism
1292018-11-28T06:50:29  <sipa> nack, we're not creating a blessed utxo set hash
1302018-11-28T06:50:29  *** shesek has quit IRC
1312018-11-28T06:50:41  <sipa> way too much power for abuse
1322018-11-28T06:51:17  <gmaxwell> ouch no, even suggesting stuff like that makes me feel really negative about the fact that the sotware even has a utxo hash at all.
1332018-11-28T06:51:18  <NicolasDorier> Well this won't break anybody software. I could make this check only once as well
1342018-11-28T06:51:54  <NicolasDorier> I see
1352018-11-28T06:52:01  <sipa> NicolasDorier: just the mere concept of having soke sort of 'official' utxo set hash sounds unacceotablw to me
1362018-11-28T06:52:02  *** shesek has joined #bitcoin-core-dev
1372018-11-28T06:52:16  <sipa> *some *unacceptable
1382018-11-28T06:52:19  <gmaxwell> esp since we now have also seen what has happened with "check utxo" like validation in ethereum, -- it's become impratical to validate ethereum without just blindly trusting utxo hashes.
1392018-11-28T06:53:14  <NicolasDorier> Yes I can understand. I am just worried that right now what we will see with those "Bitcoin Core in a box" is blind reliance on a pre-shipped UTXO Set
1402018-11-28T06:53:48  <NicolasDorier> which is even worse than publishing your UTXO Set hash somewhere public and people could check it only once
1412018-11-28T06:53:51  <sipa> i think we can probably at some point have a utxo set hash in the software, if it's accompanied with the usual review cycles, including automated CI that recomputes it... on a scale of twice a year
1422018-11-28T06:54:09  *** jhfrontz has quit IRC
1432018-11-28T06:54:23  <NicolasDorier> I think that would be acceptable
1442018-11-28T06:54:29  <gmaxwell> NicolasDorier: if the "bitcoin core in a box" then the entire software could do arbritary things, the hash it gives is meaningless.
1452018-11-28T06:54:54  <sipa> but then it's not just "whoever controls the website", but the same trust level as people already have in the sofrware anyway
1462018-11-28T06:55:02  <gmaxwell> yes, an assume valid like thing would be fine, works like regular sotware review.
1472018-11-28T06:55:08  <gmaxwell> and regular software integrity.
1482018-11-28T06:55:46  <gmaxwell> (esp since its so trivial to review, it doesn't even increase review surface)
1492018-11-28T06:56:18  <NicolasDorier> This would be perfect.
1502018-11-28T06:57:58  <NicolasDorier> The point I try to solve right now is that with BTCPay I am shipping a docker-compose that everybody can run easily. All images can be independently reviewed and built by yourself if you want. This now works on raspberry pi, and I want to guide people on how to use it on raspberry. But the sync time makes it impossible, so I am searching a good enough solution better than just shipping an untrusted utxohash
1512018-11-28T06:58:09  *** shesek has quit IRC
1522018-11-28T06:58:21  *** ada_ has joined #bitcoin-core-dev
1532018-11-28T06:58:24  <NicolasDorier> such hash in the source code would be perfect
1542018-11-28T06:59:03  <NicolasDorier> especially because this check has to be done only once
1552018-11-28T06:59:17  <NicolasDorier> only when importing an outside utxoset
1562018-11-28T07:00:21  <NicolasDorier> "Searching a good enough solution better than just shipping an untrusted utxo set" I mean
1572018-11-28T07:00:44  *** shesek has joined #bitcoin-core-dev
1582018-11-28T07:01:22  <NicolasDorier> actually does not even has to be part of bitcoind process
1592018-11-28T07:01:56  <NicolasDorier> it could just be a separate utility "bitcoinutxosetcheck utxoset.tar"
1602018-11-28T07:03:56  *** rabidus has quit IRC
1612018-11-28T07:03:57  *** grubles has joined #bitcoin-core-dev
1622018-11-28T07:16:42  *** shesek has quit IRC
1632018-11-28T07:21:23  <NicolasDorier> mmmh you know what. Actually I will just add in BTCPay a way to get the current UTXOSet hash, so someone who imported an untrusted UTXO set for his raspberry PI, can cross check with another of his own node fully synched server from beginning.
1642018-11-28T07:21:50  <NicolasDorier> Or just cross check with a friend
1652018-11-28T07:22:21  <NicolasDorier> that's good enough
1662018-11-28T07:22:34  <NicolasDorier> and without controversy
1672018-11-28T07:23:24  *** shesek has joined #bitcoin-core-dev
1682018-11-28T07:23:29  *** indistylo has joined #bitcoin-core-dev
1692018-11-28T07:25:53  *** shesek has quit IRC
1702018-11-28T07:27:08  *** shesek has joined #bitcoin-core-dev
1712018-11-28T07:33:43  *** shesek has quit IRC
1722018-11-28T07:34:27  <NicolasDorier> Ok so I think I found the ideal UX.
1732018-11-28T07:34:27  <NicolasDorier> I will add a feature in BTCPay to let people use an untrusted UTXO set.
1742018-11-28T07:34:27  <NicolasDorier> BUT once the node is fully synched, I will show a warning popup which will never go away: "Please input the UTXO set hash of the current block".
1752018-11-28T07:34:27  <NicolasDorier> I will not show the UTXO set hash of the untrusted node anywhere in BTCPay interface, so it will force them to search for it on a their own trusted node, or ask to a friend.
1762018-11-28T07:35:40  *** shesek has joined #bitcoin-core-dev
1772018-11-28T07:35:57  <NicolasDorier> I think this is even better UX than embedding known utxo hash set anywhere into bitcoin core.
1782018-11-28T07:36:18  *** shesek has quit IRC
1792018-11-28T07:37:15  *** shesek has joined #bitcoin-core-dev
1802018-11-28T07:37:40  <gmaxwell> I think that is severely worse.
1812018-11-28T07:38:30  <gmaxwell> NicolasDorier: an integrated utxo 'assume valid' doesn't change the security model at all, -- if the software was malicious the user is screwed regardless.
1822018-11-28T07:39:23  <gmaxwell> An "input one from somewhere" is almost effectively "hand blockchain.info(dejure) control over the network"-- the user then is screwed if the software is bad Or if some website is bad/hacked.
1832018-11-28T07:39:52  <NicolasDorier> I want to protect against malicious untrusted utxo set, I assume the software is not malicious (as it can be compiled from sources by the user itself already)
1842018-11-28T07:40:16  <gmaxwell> If you assume the software is not malicious then a hash in it is also not malicious.
1852018-11-28T07:40:38  <NicolasDorier> argh
1862018-11-28T07:40:48  <gmaxwell> Asking a website for the utxo hash is trusting that the website is not malicious-- might as well just have them process the payment.
1872018-11-28T07:41:24  <NicolasDorier> Well your would need to compromise both the website utxo hash and the UTXO set untrusted archive
1882018-11-28T07:41:29  <NicolasDorier> but yeah
1892018-11-28T07:41:33  <NicolasDorier> shit :(
1902018-11-28T07:42:10  *** indistylo has quit IRC
1912018-11-28T07:42:40  *** shesek has quit IRC
1922018-11-28T07:43:04  *** rabidus has joined #bitcoin-core-dev
1932018-11-28T07:43:39  *** shesek has joined #bitcoin-core-dev
1942018-11-28T07:53:53  <kallewoof> Would a peer message "getutxosethash" which returned a block height and utxo set hash be a long term solution to this or is there a better alternative?
1952018-11-28T07:54:50  <NicolasDorier> it is time consuming and ddos vector so :(
1962018-11-28T07:55:03  <NicolasDorier> it does not solve the underlying issue either
1972018-11-28T07:56:49  *** shesek has quit IRC
1982018-11-28T07:56:51  <aj> if the trusted utxo set hash comes with the software, and is updated every ~6 months; then you'd download the software, get a utxo set hash that's say 2 to 8 months out of date, download the corresponding utxo set, verify it, then download 2-8 months of blocks since then, and you're set?
1992018-11-28T07:57:51  *** shesek has joined #bitcoin-core-dev
2002018-11-28T07:57:51  *** shesek has joined #bitcoin-core-dev
2012018-11-28T07:58:17  <NicolasDorier> @aj given you have a trusted node, fully synched. And as a reviewer, you want to check if this UTXO Set Hash is correct. How would you do?
2022018-11-28T07:58:54  <NicolasDorier> I could code this hash inside BTCPay. But how other reviewer can be sure that it is not malicious
2032018-11-28T07:59:08  <NicolasDorier> (given they have their own node)
2042018-11-28T07:59:12  <aj> NicolasDorier: invalidateblock the block after it, and run the rpc call to get the hash?
2052018-11-28T07:59:19  *** shesek has quit IRC
2062018-11-28T08:00:13  <NicolasDorier> ah indeed that would work
2072018-11-28T08:00:42  *** shesek has joined #bitcoin-core-dev
2082018-11-28T08:00:55  <aj> (which i assume is gettxoutsetinfo -> hash_serialized_2 ?
2092018-11-28T08:01:29  <NicolasDorier> aj: Another idea: They use my hash to sync a new node. Then they compare the utxoset to their own node
2102018-11-28T08:01:54  <aj> if they have their own node, why don't they just copy their utxo set across?
2112018-11-28T08:02:42  <NicolasDorier> because it is pain in the ass. I want a user friendly way to put a big UTXO set tar somewhere on the cloud that people starting a new raspberry pi can rely on to get synched quick
2122018-11-28T08:04:26  <aj> NicolasDorier: that sounds fine, seems odd to expect them to already have a node is all
2132018-11-28T08:05:12  *** promag has joined #bitcoin-core-dev
2142018-11-28T08:09:41  <NicolasDorier> aj: At least for the reviewers. People running those "bitcoin core in a box" are already blindly trusting binaries anyway.
2152018-11-28T08:10:19  *** promag has quit IRC
2162018-11-28T08:10:59  <NicolasDorier> but if somebody takes time to review the code, I want him at least to be able to check that the hash I hard coded is not malicious given he has his own indendant node.
2172018-11-28T08:13:29  *** shesek has quit IRC
2182018-11-28T08:14:14  <sipa> NicolasDorier: i fear "user friendly" and "auditable full node security without central point of trust" are not really compatible
2192018-11-28T08:14:20  *** shesek has joined #bitcoin-core-dev
2202018-11-28T08:14:46  *** luke-jr has quit IRC
2212018-11-28T08:16:39  <aj> NicolasDorier: err? i was thinking in-a-box users blindly trust the hash, but the software automatically checks the utxo set they download matches the hash; that way reviewers don't generally have to download your utxo set at all (they just check the hash matches the one their node generates)
2222018-11-28T08:19:35  <NicolasDorier> aj: The problem is, if I ship the UTXO Set up to block 500.000 there is no way in Core that the hash of this UTXO set match their node. The only way is that they take my UTXO Set up to 500.000, then let it sync to the latest block, then check that the two nodes (the one they trust, and the one where they used this UTXO set) match.
2232018-11-28T08:19:51  *** shesek has quit IRC
2242018-11-28T08:19:59  <NicolasDorier> "there is no way to *check in core" I mean
2252018-11-28T08:20:01  *** luke-jr has joined #bitcoin-core-dev
2262018-11-28T08:20:16  <sipa> why do you need the utxo set?
2272018-11-28T08:20:19  *** shesek has joined #bitcoin-core-dev
2282018-11-28T08:21:09  <NicolasDorier> sipa: well to check  the payments are real? :p
2292018-11-28T08:21:43  <sipa> NicolasDorier: why do you need the historical utxo set?
2302018-11-28T08:21:59  *** Murch has joined #bitcoin-core-dev
2312018-11-28T08:22:08  *** shesek has quit IRC
2322018-11-28T08:22:47  <NicolasDorier> So that raspberry pi user can sync fast. They would download it the utxo set at block 500.000 then sync up to the latest block.
2332018-11-28T08:23:10  *** shesek has joined #bitcoin-core-dev
2342018-11-28T08:24:48  <sipa> NicolasDorier: i feel that introducing a convenient way to run a "full nkde" that relies on too centralized ways of determining that set is far worse than using a loght client
2352018-11-28T08:24:51  <aj> NicolasDorier: if you're doing rc1 of your next release now, why wouldn't you pick a recent hash, say 200 blocks old like 551600? invalidateblock/txoutsetinfo only takes a couple of minutes to run to review that?
2362018-11-28T08:25:25  <NicolasDorier> aj: yep true, this would work
2372018-11-28T08:28:00  <aj> $ time (blk=$(bitcoin-cli getblockhash 551601); echo $blk; bitcoin-cli invalidateblock $blk; bitcoin-cli gettxoutsetinfo | grep hash_serial; bitcoin-cli reconsiderblock $blk)    # --> 666550387c3f5fa8e9353ce561fcee2a164022d31b97affd7c982388f19a4904as the hash, took about 1m12 all up
2382018-11-28T08:28:15  <NicolasDorier> sipa: Given I trust my software and my software can check the tar shasum of the "historical utxoset at block 500.000", then it is fine.
2392018-11-28T08:28:15  <NicolasDorier> Now how do I trust the software? By reviewing the code. But by reviewing the code I see this shasum of historical utxoset. How can I review this hash?
2402018-11-28T08:28:15  <NicolasDorier> Either by doing what aj said (invalidateblock up to the height) or just using this UTXO set to sync up to now and cross check that UTXO set hash of this node is the same than another of my node that I fully synched from the beginning.
2412018-11-28T08:28:47  <NicolasDorier> aj: though the invalidateblock is not possible if the node you trust is pruned
2422018-11-28T08:29:01  <aj> NicolasDorier: going back a few hundred blocks should be fine even if it's pruned
2432018-11-28T08:29:30  <NicolasDorier> Yes true, this would work as well
2442018-11-28T08:31:04  <NicolasDorier> While I distribute the UTXO set centrally, and ship this hash in the product, anybody would be able to check against it.
2452018-11-28T08:31:25  <sipa> i don't like "anyone can check"
2462018-11-28T08:31:35  <sipa> people don't
2472018-11-28T08:32:41  <gmaxwell> the ethereum ecosystem shows this pretty perfectly... node falls behind, blindly accept the state.
2482018-11-28T08:33:47  <gmaxwell> people don't check.  And any that did would just check some centeralized website. The security in that case is pure pretext.
2492018-11-28T08:33:57  <NicolasDorier> Well as people blindly run binaries shipped by core, and don't check they can reproduce the build. But at least checking this hash is easier than doign a gitian build.
2502018-11-28T08:34:34  <gmaxwell> a lot of people do check that they can reproduce the build, and publish attestations too.
2512018-11-28T08:34:38  *** shesek has quit IRC
2522018-11-28T08:34:57  <NicolasDorier> then why would they not do it for the hash?
2532018-11-28T08:34:58  <aj> sipa: the alternative to "don't check but can" that people will actually adopt is "don't check and can't" though, which seems worse...
2542018-11-28T08:35:03  *** shesek has joined #bitcoin-core-dev
2552018-11-28T08:35:18  <gmaxwell> I think it's not worse.
2562018-11-28T08:35:20  <sipa> aj: that's fair
2572018-11-28T08:35:36  <gmaxwell> a _dishonest_ security model is worse than being insecure in practice and lying to the whole world and yourself about it.
2582018-11-28T08:36:03  *** shesek has quit IRC
2592018-11-28T08:36:24  <gmaxwell> maybe more people should have given a shit since _2011_ that making it absurdly expensive to sync would be a problem.
2602018-11-28T08:36:39  <gmaxwell> and instead worked to prevent that instead of taking an unsustainable load and doubling it.
2612018-11-28T08:36:50  <gmaxwell> but whats past is past.
2622018-11-28T08:36:59  <NicolasDorier> well this would have happened one day or another
2632018-11-28T08:37:42  <sipa> NicolasDorier: just so we're talking about the same thing, i do not think it is inherently necessary that every full nkde forever validates all of history
2642018-11-28T08:38:01  <gmaxwell> not necessarily,  e.g. the work by phantomcircuit and luke-jr that showed the maximum rate of blockchain increase that would have kept sync time constant under the assumption of some year over year percentage increase in sync performance.
2652018-11-28T08:38:11  *** shesek has joined #bitcoin-core-dev
2662018-11-28T08:38:29  <gmaxwell> in 2015 the figure for that would have been roughly 300kbyte blocks.
2672018-11-28T08:38:51  <gmaxwell> in any case, water under the bridge.
2682018-11-28T08:39:11  <gmaxwell> It sound like whats previously been proposed for utxo assumevalid would work fine for you, except it doesn't exist yet.
2692018-11-28T08:39:17  <sipa> there are perfectly reasonable solutions to avoid that, including a deeply buried infrequently updated assumevalid utxo set hash
2702018-11-28T08:39:44  <NicolasDorier> I would like at least that node which do not fully validate has a way to ring the bells if their utxo stop matching with other people, or with their own node on a different server which fully validated everything.
2712018-11-28T08:39:51  <gmaxwell> Please do not poison the well by proposing "check against a website"... all that is going to do is create a big fight over it and cause people to also fight against more reasonable measures.
2722018-11-28T08:40:15  <NicolasDorier> yeah no worry I won't do this
2732018-11-28T08:40:27  <gmaxwell> if their software is malicious then there is no way they can count on it to warn them...
2742018-11-28T08:42:15  <aj> gmaxwell: if their software isn't malicious but the utxo download site is, they could get a warning at least
2752018-11-28T08:43:27  *** tripleslash has quit IRC
2762018-11-28T08:44:23  <gmaxwell> aj: download site? it should be getting it from the network and checking it against the software.
2772018-11-28T08:46:27  <aj> gmaxwell: maybe, but there's a lot more implementation to do for that
2782018-11-28T08:46:37  *** shesek has quit IRC
2792018-11-28T08:47:32  *** shesek has joined #bitcoin-core-dev
2802018-11-28T08:47:41  <aj> gmaxwell: well, unless you're happy with "network" being "torrent of the utxo set at a point in time"
2812018-11-28T08:47:46  <gmaxwell> It's been implemented before.
2822018-11-28T08:48:24  <aj> gmaxwell: for a utxo set up to 6 or 8 months old, or just the current (rolling) utxo set?
2832018-11-28T08:48:31  <gmaxwell> I guess like actually improving the protocol might get in the way of five refactors a day.
2842018-11-28T08:48:43  <sipa> come on
2852018-11-28T08:48:57  <gmaxwell> aj: there was a snapshot one implemented previously.
2862018-11-28T08:50:28  <gmaxwell> It has been _years_ now since we've made a protocol improvement, and when an need gets brought up for one it seems like it's just a question of how fast we could enable trusting a website...
2872018-11-28T08:50:44  <gmaxwell> It's bad enough when people outside of regular development act helpless about limitations that could be improved.
2882018-11-28T08:50:58  *** shesek has quit IRC
2892018-11-28T08:51:23  <aj> gmaxwell: url or search term suggestion for the previous implementation?
2902018-11-28T08:52:32  <gmaxwell> some randos github repo-- they didn't hang around and keep trying to contribute when their efforts didn't make prompt progress, I'm searching
2912018-11-28T08:53:09  *** shesek has joined #bitcoin-core-dev
2922018-11-28T08:54:53  *** tripleslash has joined #bitcoin-core-dev
2932018-11-28T09:04:56  *** shesek has quit IRC
2942018-11-28T09:05:51  *** shesek has joined #bitcoin-core-dev
2952018-11-28T09:05:51  *** shesek has joined #bitcoin-core-dev
2962018-11-28T09:05:59  *** elichai2 has joined #bitcoin-core-dev
2972018-11-28T09:06:53  *** phwalkr has joined #bitcoin-core-dev
2982018-11-28T09:08:58  *** Murch has quit IRC
2992018-11-28T09:10:04  *** setpill has joined #bitcoin-core-dev
3002018-11-28T09:11:19  *** phwalkr has quit IRC
3012018-11-28T09:15:38  <cjd> I was quite impressed by Peter's work on UTXO proofs
3022018-11-28T09:17:12  <cjd> ( https://petertodd.org/2016/delayed-txo-commitments )
3032018-11-28T09:17:15  *** shesek has quit IRC
3042018-11-28T09:17:33  <midnightmagic> holy crap cjd is talking \o
3052018-11-28T09:17:48  <cjd> hey midnight, long time no see :)
3062018-11-28T09:17:57  <midnightmagic> :-)
3072018-11-28T09:17:57  *** bitcoin-git has joined #bitcoin-core-dev
3082018-11-28T09:17:57  <bitcoin-git> [bitcoin] Mountains-and-rivers opened pull request #14825: 0.17 (master...0.17) https://github.com/bitcoin/bitcoin/pull/14825
3092018-11-28T09:17:57  *** bitcoin-git has left #bitcoin-core-dev
3102018-11-28T09:18:01  *** shesek has joined #bitcoin-core-dev
3112018-11-28T09:18:01  *** shesek has joined #bitcoin-core-dev
3122018-11-28T09:18:17  <sipa> cjd: there has been more recent work around that too
3132018-11-28T09:18:25  <cjd> oh? link?
3142018-11-28T09:19:23  *** bitcoin-git has joined #bitcoin-core-dev
3152018-11-28T09:19:23  <bitcoin-git> [bitcoin] laanwj closed pull request #14825: 0.17 (master...0.17) https://github.com/bitcoin/bitcoin/pull/14825
3162018-11-28T09:19:23  *** bitcoin-git has left #bitcoin-core-dev
3172018-11-28T09:19:34  <sipa> cjd: at least bram cohen has come up with a hybrid nodes-still-keep-spentness-but-not-utxos-themselves (search for "utxo bitset")
3182018-11-28T09:19:53  <sipa> adiabat has been working on a practical merkle tree based system
3192018-11-28T09:20:30  <cjd> found this: https://diyhpl.us/wiki/transcripts/sf-bitcoin-meetup/2017-07-08-bram-cohen-merkle-sets/
3202018-11-28T09:20:32  <sipa> latest scaling bitcoin had a talk on improvements to cryptographic accumulators to make them more usable for this kind of application
3212018-11-28T09:20:51  <sipa> yeah, it's in there; there is also a ml post
3222018-11-28T09:21:26  <sipa> i have written a post on rolling utxo hashes (which don't permit compact proofs, but may help comparing utxo sets)
3232018-11-28T09:22:03  *** promag has joined #bitcoin-core-dev
3242018-11-28T09:22:48  <gmaxwell> aj: unfortunately the impl before came from someone who wasn't a regular so they didn't use our ordinary language to talk about it, so I'm having a damnd hard time grepping up the link.
3252018-11-28T09:23:12  <sipa> gmaxwell: it was a bitcointalk post afaik
3262018-11-28T09:24:11  *** timothy has joined #bitcoin-core-dev
3272018-11-28T09:24:12  <cjd> I'm kind of cold on anything that requires shor attackable crypto at the infrastructure level, but that said I think a lot of these things are still using hashes
3282018-11-28T09:24:37  <cjd> And I distinguish between infrastructure level (hashes, merkle trees etc) from the spending level (signing a transaction)
3292018-11-28T09:26:00  <dongcarl> A v0 WitnessProgram with a size that's not 20 nor 32 bytes is still a valid WitnessProgram, but will fail, is that a correct distinction?
3302018-11-28T09:26:11  <cjd> it would be nice to go all in on the wild crypto and be able to make everything anonymous, but I think that should be kept as an option to put your money into the black box and then take it out again, knowing that some major advancement in math or quantum computers might cause the black box to implode
3312018-11-28T09:26:13  *** shesek has quit IRC
3322018-11-28T09:26:44  <gmaxwell> sipa: ah, it was also several weeks of talk in IRC.
3332018-11-28T09:26:51  <gmaxwell> which is what I was trying to find.
3342018-11-28T09:27:12  <sipa> dongcarl: correct
3352018-11-28T09:27:30  *** shesek has joined #bitcoin-core-dev
3362018-11-28T09:27:38  <sipa> dongcarl: though i'm not sure that that distinction is observable
3372018-11-28T09:28:19  <dongcarl> sipa: `CScript::IsWitnessProgram` seems to not check that a v0 WitnessProgram is either 20 or 32bytes
3382018-11-28T09:28:23  <gmaxwell> as there is no input that will hash to match it.
3392018-11-28T09:28:28  <sipa> dongcarl: correct
3402018-11-28T09:28:45  <dongcarl> right right
3412018-11-28T09:28:54  <gmaxwell> dongcarl: a complicated thing with consensus rules is "which of the infinite set of implied consensus rules should be called consensus rules"?
3422018-11-28T09:29:10  <sipa> but the only effect of something being a witness output is that it means a witness can be present when spending it
3432018-11-28T09:29:35  <sipa> however, in the case of a v0 with not-20/32 size, there is no valid spend
3442018-11-28T09:30:08  <gmaxwell> like, yes maybe bitcoin core has a branch that checks the size and terminates... but without that branch it would still reject those cases because the hash function (a size triggered OR of two functions) will never match for inputs of other sizes.
3452018-11-28T09:30:50  <sipa> right, operational semantics can differ from the validaty rules...
3462018-11-28T09:31:15  <sipa> as in one (invalid) case we may check signatures and in another invalid case we reject before reaching that point
3472018-11-28T09:31:20  <gmaxwell> like it will also fail if your input is PUSH("RICK") OP_ROLL, but we wouldn't say that we have a consensus rule that the witness scripthash can't be PUSH("RICK") OP_ROLL.
3482018-11-28T09:31:44  <gmaxwell> Even if we were to add code to specifically catch that case because some clown was spamming with it and we thought it would be useful to fail faster.
3492018-11-28T09:32:03  <gmaxwell> (or more often, because being specific can make the semantics more clear)
3502018-11-28T09:32:31  <dongcarl> gmaxwell: ah... makes sense... some rules are stated, and some rules are the consequence of other rules
3512018-11-28T09:32:59  <sipa> dongcarl: in any case, by the terminology of the BIP and the source code, yes, a v0 21-byte output is a witness output
3522018-11-28T09:33:08  <gmaxwell> and sometimes we make implied rules concrete ... and then only later take them out again.
3532018-11-28T09:33:29  <sipa> however, whether it is or not has no effect (i think!) on any consensus observable effect
3542018-11-28T09:33:47  <gmaxwell> as which of the implied consensus rules we implement concretely is just an implementation choice...
3552018-11-28T09:34:06  <gmaxwell> sipa: that probably has some effect on RPC outputs.
3562018-11-28T09:34:33  <dongcarl> sipa: gotcha, I'm looking at the test case PR for `IsWitnessProgram`, so wanted to double check
3572018-11-28T09:35:10  <dongcarl> gmaxwell: Soo... consensus is really just implementation?
3582018-11-28T09:35:49  <sipa> dongcarl: ultimately, yes - but i don't think that's the conclusion here
3592018-11-28T09:36:39  <sipa> there is a set of intended rules, but there are still many ways of mapping those rules to code that are all identical in terms of observable behavior
3602018-11-28T09:37:19  <sipa> and the implentation may choose to make distinctions that don't exist in the observable rules
3612018-11-28T09:37:57  <sipa> for example, bitcoin core will use a very different codepath for an ecdsa signature that is too long vs one that is just invalid
3622018-11-28T09:37:59  <gmaxwell> I normally think of the consensus rules as the MINIMAL set of rules that implement the 'consensus functionality'.
3632018-11-28T09:38:28  <sipa> but the rules that people understand the system has doesn't make this distinction at all
3642018-11-28T09:39:01  <gmaxwell> For implementation reasons we don't implement "the consensus rules" we implement some isomorphic set of rules. They behave the same for consensus purposes, but have some implementation advantages.
3652018-11-28T09:40:08  <gmaxwell> E.g. cheap tests for expensive failure conditions... like checking the length of a witness hash, we don't have to-- a wrong length won't ever agree with the hasher, but perhaps the code is more obviously correct if the lengths are checked.
3662018-11-28T09:42:12  <cjd> This all reminds me of the recent(ish) work that was done at inria on modelling the SSL state machine
3672018-11-28T09:42:38  <cjd> Source of that handful of attacks which were published in the past 3 years
3682018-11-28T09:42:39  <dongcarl> Ahhhh okay I think I get it... Sometimes short-circuiting (even when consensus doesn't dictate it) can have advantages in terms of implementation
3692018-11-28T09:43:10  <sipa> dongcarl: exactly
3702018-11-28T09:43:25  <sipa> consensus only outputs "valid" or "invalid"
3712018-11-28T09:43:34  <sipa> it doesn't even report why something was invalid
3722018-11-28T09:44:11  <sipa> (though that may in some cases be obserable on the P2P protocol by bans and corruptionpossible flag)
3732018-11-28T09:45:48  <gmaxwell> though thats also one of the reasons I don't like having things like reject reasons visible... they're hard to make stable without really confining the specifics of the implementation.
3742018-11-28T09:46:02  <gmaxwell> "Your thing was wrong for 5 reasons, but we're only going to tell you one of them."
3752018-11-28T09:46:51  <sipa> and after a refactor, we'll tell you about another one instead
3762018-11-28T09:48:49  *** Guest80 has joined #bitcoin-core-dev
3772018-11-28T09:49:26  <Guest80> Hello!
3782018-11-28T09:49:37  <Guest80> Anybody here?
3792018-11-28T09:49:43  <gmaxwell> nope
3802018-11-28T09:49:58  <Guest80> Funny...
3812018-11-28T09:50:02  <Guest80> ;-)
3822018-11-28T09:50:20  <dongcarl> gmaxwell: Huh... I was actually thinking that errors need error codes in Bitcoin... But perhaps that's a bad idea...
3832018-11-28T09:50:26  <Guest80> Anybody here experienced with bitcoin core build?
3842018-11-28T09:51:15  <Guest80> My simplified question is: Ho to build Windows installers?
3852018-11-28T09:51:35  <dongcarl> Guest80: https://github.com/bitcoin/bitcoin/blob/master/doc/build-windows.md
3862018-11-28T09:51:47  <Guest80> I can build Windows binaries but they all Stand Alone ones.
3872018-11-28T09:51:50  *** shesek has quit IRC
3882018-11-28T09:52:11  <Guest80> Thanks, I'm familiar with the document you linked.
3892018-11-28T09:52:53  <dongcarl> Guest80: you can build a Windows installer using other tools, it's not in the scope of the project I don't think
3902018-11-28T09:53:35  <Guest80> I'm here because that document is no help at all.
3912018-11-28T09:53:40  <Guest80> Thanks!
3922018-11-28T09:53:42  <sipa> dongcarl: libconsensus will give you error codes
3932018-11-28T09:53:56  <sipa> for script validity at least
3942018-11-28T09:54:04  <Guest80> Bitcoin.org has Windows installers. They build them somehow.
3952018-11-28T09:54:29  <sipa> Guest80: using a deterministic build environment
3962018-11-28T09:54:43  <sipa> which is fully scripted
3972018-11-28T09:54:55  <sipa> but runs in a linux vm
3982018-11-28T09:55:10  <dongcarl> sipa: Oh cool... So how does it decide what error to point out?
3992018-11-28T09:55:19  <Guest80> I build under Ubuntu 10.04.1 LTS
4002018-11-28T09:55:36  <Guest80> That Ubuntu runs as a VM.
4012018-11-28T09:55:37  <gmaxwell> dongcarl: well I don't like them, because either we don't keep them stable which maybe breaks things. ... or we have an implementation suicide pact where it's really hard to change stuff just due to preserving errors.
4022018-11-28T09:55:41  <dongcarl> Or does it suffer from the problem of pointing out the first problem it finds and probably will point out a different one if we refactor?
4032018-11-28T09:55:53  <gmaxwell> exactly
4042018-11-28T09:56:46  <sipa> thankfully, that part of the consensus code (script interpreter) does not need much changes
4052018-11-28T09:57:49  <dongcarl> Gotcha
4062018-11-28T09:58:27  <sipa> the types of failures around blkcks and transactions changs more often
4072018-11-28T10:04:16  <promag> sipa: GetAffectedKeys could be GetAffectedPubKeys?
4082018-11-28T10:04:18  <Guest80> Again, the link you linked is irrelevant.
4092018-11-28T10:04:44  <Guest80> I am building for Windows target under Ubuntu.
4102018-11-28T10:05:06  <Guest80> I am not building under Windows.
4112018-11-28T10:05:34  <Guest80> I can build "by the book". That's not the problem.
4122018-11-28T10:05:34  <sipa> Guest80: yes, follow the gitian guide
4132018-11-28T10:05:47  <sipa> promag: it returns key kds
4142018-11-28T10:05:50  <sipa> key ids
4152018-11-28T10:05:58  <sipa> key ids identify keypairs
4162018-11-28T10:06:32  *** phwalkr has joined #bitcoin-core-dev
4172018-11-28T10:06:46  <Guest80> The problem is that the results of the build are Stand Alone Windows binaries, and not the Windows installer.
4182018-11-28T10:07:17  <sipa> gitian also produces the installer
4192018-11-28T10:07:27  <Guest80> And I need the Windows installer.
4202018-11-28T10:07:47  <Guest80> Well, it does not produce the installer.
4212018-11-28T10:07:55  <sipa> yes it does
4222018-11-28T10:08:07  <gmaxwell> I believe the gitian build makes the installer.  You need to get the extracted signatures for it to produce a signed installer.
4232018-11-28T10:08:12  <Guest80> It collects everythin in one folder, but none of themis the installer.
4242018-11-28T10:09:09  <Guest80> If the Gitanian build makes the installer than it does it with a special switch or something. NOT by default.
4252018-11-28T10:09:39  <sipa> https://github.com/bitcoin-core/gitian.sigs/blob/master/0.17.0-win-unsigned/achow101/bitcoin-win-0.17-build.assert
4262018-11-28T10:09:58  <sipa> that's the build assertion for achow101's build of 0.17.0
4272018-11-28T10:10:05  <sipa> the output includes the installer
4282018-11-28T10:10:20  <Guest80> Thanks!
4292018-11-28T10:10:32  <Guest80> Thanks sipa
4302018-11-28T10:10:35  <sipa> so i believe you are wrong
4312018-11-28T10:10:53  <Guest80> Thanks gmaxwell
4322018-11-28T10:11:06  <sipa> but i have not run gitian builds in a while myself
4332018-11-28T10:22:14  <promag> sipa: does the branch comes from face/off movie? 201810_die_caffectedkeysvisitor_die
4342018-11-28T10:22:33  *** spinza has quit IRC
4352018-11-28T10:25:11  <Guest80> Again, the Bitcoin.org can have whatever build system, it doesn't help to see the result of their build.
4362018-11-28T10:25:48  *** Soligor has quit IRC
4372018-11-28T10:26:02  <Guest80> I'm still with the Gitanian build that does not produce installers.
4382018-11-28T10:27:43  *** spinza has joined #bitcoin-core-dev
4392018-11-28T10:30:54  *** Victorsueca has quit IRC
4402018-11-28T10:32:11  *** Victorsueca has joined #bitcoin-core-dev
4412018-11-28T10:35:31  *** Guest80 has quit IRC
4422018-11-28T10:44:23  <sipa> promag: i believe it's been in a number of popular media works, including the simpsons
4432018-11-28T10:47:38  <promag> sipa: is this worth it https://github.com/promag/bitcoin/commit/59f62571bc09df01373295d9aac5a485a2ee2eaa ?
4442018-11-28T10:53:45  *** EagleTM has joined #bitcoin-core-dev
4452018-11-28T11:04:39  *** booyah has quit IRC
4462018-11-28T11:05:08  *** booyah has joined #bitcoin-core-dev
4472018-11-28T11:15:21  *** wxss has joined #bitcoin-core-dev
4482018-11-28T11:17:07  *** bitcoin-git has joined #bitcoin-core-dev
4492018-11-28T11:17:07  <bitcoin-git> [bitcoin] promag opened pull request #14826: Avoid expanding descriptor scriptPubKeys (master...2018-11-faster-descriptor-expand) https://github.com/bitcoin/bitcoin/pull/14826
4502018-11-28T11:17:07  *** bitcoin-git has left #bitcoin-core-dev
4512018-11-28T11:29:36  *** bitcoin-git has joined #bitcoin-core-dev
4522018-11-28T11:29:36  <bitcoin-git> [bitcoin] 3s3s opened pull request #14827: remove fCheckDuplicateInputs (master...master) https://github.com/bitcoin/bitcoin/pull/14827
4532018-11-28T11:29:36  *** bitcoin-git has left #bitcoin-core-dev
4542018-11-28T11:30:43  *** CubicEarth has joined #bitcoin-core-dev
4552018-11-28T11:32:29  *** EagleTM has quit IRC
4562018-11-28T11:53:41  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4572018-11-28T11:55:40  *** shesek has joined #bitcoin-core-dev
4582018-11-28T11:55:40  *** shesek has joined #bitcoin-core-dev
4592018-11-28T12:01:56  *** EagleTM has joined #bitcoin-core-dev
4602018-11-28T12:09:56  *** AaronvanW has joined #bitcoin-core-dev
4612018-11-28T12:10:05  *** EagleTM has quit IRC
4622018-11-28T12:20:01  *** dviola has joined #bitcoin-core-dev
4632018-11-28T12:21:02  *** rh0nj has quit IRC
4642018-11-28T12:22:07  *** rh0nj has joined #bitcoin-core-dev
4652018-11-28T12:26:20  *** bitcoin-git has joined #bitcoin-core-dev
4662018-11-28T12:26:21  <bitcoin-git> [bitcoin] promag opened pull request #14828: qt: Remove hidden columns in coin control dialog (master...2018-11-coincontroldialog) https://github.com/bitcoin/bitcoin/pull/14828
4672018-11-28T12:26:21  *** bitcoin-git has left #bitcoin-core-dev
4682018-11-28T12:51:30  *** zivl has joined #bitcoin-core-dev
4692018-11-28T12:56:52  *** chenpo has joined #bitcoin-core-dev
4702018-11-28T12:57:36  *** chenpo_ has joined #bitcoin-core-dev
4712018-11-28T12:58:31  *** indistylo has joined #bitcoin-core-dev
4722018-11-28T13:01:09  *** chenpo has quit IRC
4732018-11-28T13:01:46  *** Chris_Stewart_5 has quit IRC
4742018-11-28T13:09:12  *** murchandamus has quit IRC
4752018-11-28T13:10:42  *** murchandamus has joined #bitcoin-core-dev
4762018-11-28T13:12:53  *** tryphe has quit IRC
4772018-11-28T13:13:26  *** tryphe has joined #bitcoin-core-dev
4782018-11-28T13:16:26  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4792018-11-28T13:25:16  *** Ryan___ has joined #bitcoin-core-dev
4802018-11-28T13:43:15  *** rex4539 has quit IRC
4812018-11-28T13:51:20  *** shesek has quit IRC
4822018-11-28T14:03:48  *** Chris_Stewart_5 has quit IRC
4832018-11-28T14:07:16  *** jhfrontz has joined #bitcoin-core-dev
4842018-11-28T14:10:47  *** promag has quit IRC
4852018-11-28T14:12:41  *** spinza has quit IRC
4862018-11-28T14:15:03  *** bitcoin-git has joined #bitcoin-core-dev
4872018-11-28T14:15:04  <bitcoin-git> [bitcoin] fanquake closed pull request #14827: remove fCheckDuplicateInputs (master...master) https://github.com/bitcoin/bitcoin/pull/14827
4882018-11-28T14:15:04  *** bitcoin-git has left #bitcoin-core-dev
4892018-11-28T14:22:54  *** spinza has joined #bitcoin-core-dev
4902018-11-28T14:31:38  *** bitcoin-git has joined #bitcoin-core-dev
4912018-11-28T14:31:39  <bitcoin-git> [bitcoin] hebasto closed pull request #14817: qt: Remove unnecessary columns in Coin Selection window (#11811) (master...20181126-fix-hidden-columns) https://github.com/bitcoin/bitcoin/pull/14817
4922018-11-28T14:31:39  *** bitcoin-git has left #bitcoin-core-dev
4932018-11-28T14:33:04  *** promag has joined #bitcoin-core-dev
4942018-11-28T14:40:16  *** Guyver2 has joined #bitcoin-core-dev
4952018-11-28T14:40:25  *** promag has quit IRC
4962018-11-28T14:44:56  *** promag has joined #bitcoin-core-dev
4972018-11-28T15:05:15  *** arubi has quit IRC
4982018-11-28T15:05:55  *** arubi has joined #bitcoin-core-dev
4992018-11-28T15:06:36  *** shesek has joined #bitcoin-core-dev
5002018-11-28T15:06:36  *** shesek has joined #bitcoin-core-dev
5012018-11-28T15:11:45  *** Chris_Stewart_5 has joined #bitcoin-core-dev
5022018-11-28T15:14:28  *** Victorsueca has quit IRC
5032018-11-28T15:14:43  *** setpill has quit IRC
5042018-11-28T15:22:12  *** rex4539 has joined #bitcoin-core-dev
5052018-11-28T15:34:27  *** Victorsueca has joined #bitcoin-core-dev
5062018-11-28T15:36:56  *** promag_ has joined #bitcoin-core-dev
5072018-11-28T15:40:23  *** promag has quit IRC
5082018-11-28T15:40:57  *** promag_ is now known as promag
5092018-11-28T15:42:32  *** bitcoin-git has joined #bitcoin-core-dev
5102018-11-28T15:42:33  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/600b85bb4172...9ebfe0e92737
5112018-11-28T15:42:34  <bitcoin-git> bitcoin/master 29aeed1 Luke Dashjr: Bugfix: test/functional/mempool_accept: Ensure oversize transaction is actually oversize...
5122018-11-28T15:42:34  <bitcoin-git> bitcoin/master 9ebfe0e MarcoFalke: Merge #14819: Bugfix: test/functional/mempool_accept: Ensure oversize transaction is actually oversize...
5132018-11-28T15:42:35  *** bitcoin-git has left #bitcoin-core-dev
5142018-11-28T15:42:50  *** extnct24 has joined #bitcoin-core-dev
5152018-11-28T15:44:08  *** bitcoin-git has joined #bitcoin-core-dev
5162018-11-28T15:44:09  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #14819: Bugfix: test/functional/mempool_accept: Ensure oversize transaction is actually oversize (master...bugfix_test_mempool_accept) https://github.com/bitcoin/bitcoin/pull/14819
5172018-11-28T15:44:09  *** bitcoin-git has left #bitcoin-core-dev
5182018-11-28T15:57:51  *** bralyclow has joined #bitcoin-core-dev
5192018-11-28T16:02:08  *** bralyclow has quit IRC
5202018-11-28T16:09:14  *** bitcoin-git has joined #bitcoin-core-dev
5212018-11-28T16:09:15  <bitcoin-git> [bitcoin] MarcoFalke pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/9ebfe0e92737...0a452d02cebb
5222018-11-28T16:09:15  <bitcoin-git> bitcoin/master b312cd7 practicalswift: Add missing locking annotations
5232018-11-28T16:09:16  <bitcoin-git> bitcoin/master 4894133 practicalswift: Add missing lock in CNode::copyStats(...)
5242018-11-28T16:09:16  <bitcoin-git> bitcoin/master 0a452d0 MarcoFalke: Merge #13123: net: Add Clang thread safety annotations for guarded variables in the networking code...
5252018-11-28T16:09:17  *** bitcoin-git has left #bitcoin-core-dev
5262018-11-28T16:09:41  *** bitcoin-git has joined #bitcoin-core-dev
5272018-11-28T16:09:41  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #13123: net: Add Clang thread safety annotations for guarded variables in the networking code (master...net-guarded-by) https://github.com/bitcoin/bitcoin/pull/13123
5282018-11-28T16:09:41  *** bitcoin-git has left #bitcoin-core-dev
5292018-11-28T16:12:31  *** bitcoin-git has joined #bitcoin-core-dev
5302018-11-28T16:12:31  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #14487: Constexpr Everything Part 1: Constants (master...patch-3) https://github.com/bitcoin/bitcoin/pull/14487
5312018-11-28T16:12:31  *** bitcoin-git has left #bitcoin-core-dev
5322018-11-28T16:15:22  *** bitcoin-git has joined #bitcoin-core-dev
5332018-11-28T16:15:23  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0a452d02cebb...60b20c869f8d
5342018-11-28T16:15:23  <bitcoin-git> bitcoin/master fa5cef0 MarcoFalke: bench: Destroy wallet txs instead of leaking their memory
5352018-11-28T16:15:24  <bitcoin-git> bitcoin/master 60b20c8 MarcoFalke: Merge #14822: bench: Destroy wallet txs instead of leaking their memory...
5362018-11-28T16:15:24  *** bitcoin-git has left #bitcoin-core-dev
5372018-11-28T16:15:50  <promag> https://ci.appveyor.com/project/DrahtBot/bitcoin/builds/20618902
5382018-11-28T16:16:27  <promag> yet another connection problem
5392018-11-28T16:16:33  *** bitcoin-git has joined #bitcoin-core-dev
5402018-11-28T16:16:34  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #14822: bench: Destroy wallet txs instead of leaking their memory (master...Mf1811-benchWalletTxs) https://github.com/bitcoin/bitcoin/pull/14822
5412018-11-28T16:16:34  *** bitcoin-git has left #bitcoin-core-dev
5422018-11-28T16:17:47  <promag> please consider #14670
5432018-11-28T16:17:49  <gribble> https://github.com/bitcoin/bitcoin/issues/14670 | http: Fix HTTP server shutdown by promag · Pull Request #14670 · bitcoin/bitcoin · GitHub
5442018-11-28T16:18:33  *** indistylo has quit IRC
5452018-11-28T16:36:42  *** ada_ has quit IRC
5462018-11-28T16:54:06  *** michaelsdunn1 has joined #bitcoin-core-dev
5472018-11-28T16:55:15  *** promag has quit IRC
5482018-11-28T16:57:58  *** rex4539 has quit IRC
5492018-11-28T16:59:17  *** michaelsdunn1 has quit IRC
5502018-11-28T16:59:33  *** michaelsdunn1 has joined #bitcoin-core-dev
5512018-11-28T17:02:01  *** rh0nj has quit IRC
5522018-11-28T17:03:08  *** rh0nj has joined #bitcoin-core-dev
5532018-11-28T17:07:48  *** wxss has quit IRC
5542018-11-28T17:09:39  *** shesek has quit IRC
5552018-11-28T17:17:36  *** jouke_ has joined #bitcoin-core-dev
5562018-11-28T17:19:09  *** michaelsdunn1 has quit IRC
5572018-11-28T17:26:14  *** michaelsdunn1 has joined #bitcoin-core-dev
5582018-11-28T17:34:48  *** jarthur has joined #bitcoin-core-dev
5592018-11-28T17:36:27  *** michaelsdunn1 has quit IRC
5602018-11-28T17:37:16  *** fabianfabian has joined #bitcoin-core-dev
5612018-11-28T17:44:25  *** schnerchi has quit IRC
5622018-11-28T17:48:40  *** rex4539 has joined #bitcoin-core-dev
5632018-11-28T17:50:30  *** Murch has joined #bitcoin-core-dev
5642018-11-28T18:11:42  *** grubles_ has joined #bitcoin-core-dev
5652018-11-28T18:14:03  *** grubles has quit IRC
5662018-11-28T18:16:54  *** Chris_Stewart_5 has quit IRC
5672018-11-28T18:23:18  *** jarthur has quit IRC
5682018-11-28T18:39:26  *** Chris_Stewart_5 has joined #bitcoin-core-dev
5692018-11-28T18:41:28  *** michaelsdunn1 has joined #bitcoin-core-dev
5702018-11-28T18:42:00  *** davec has quit IRC
5712018-11-28T18:44:06  *** davec has joined #bitcoin-core-dev
5722018-11-28T18:48:12  *** davec has quit IRC
5732018-11-28T18:48:29  *** jarthur has joined #bitcoin-core-dev
5742018-11-28T18:50:26  *** grubles_ is now known as grubles
5752018-11-28T19:06:58  *** jarthur has quit IRC
5762018-11-28T19:20:03  *** timothy has quit IRC
5772018-11-28T19:28:33  *** Madars has joined #bitcoin-core-dev
5782018-11-28T19:38:22  *** spinza has quit IRC
5792018-11-28T19:47:45  *** jarthur has joined #bitcoin-core-dev
5802018-11-28T19:58:14  *** dviola has quit IRC
5812018-11-28T20:03:29  *** xames has joined #bitcoin-core-dev
5822018-11-28T20:07:55  *** xames has quit IRC
5832018-11-28T20:08:58  <arubi> ##hwi is invite only now?
5842018-11-28T20:14:19  <gwillen> arubi: I have registered a complaint
5852018-11-28T20:14:29  <arubi> cheers
5862018-11-28T20:14:40  <gwillen> I can't actually speak there so I registered it via other means :-P
5872018-11-28T20:14:52  <arubi> :)
5882018-11-28T20:15:10  <gwillen> provoostenator: actually I suppose pinging you here works too ^
5892018-11-28T20:18:01  *** dviola has joined #bitcoin-core-dev
5902018-11-28T20:22:36  *** drexl has joined #bitcoin-core-dev
5912018-11-28T20:28:51  *** promag has joined #bitcoin-core-dev
5922018-11-28T20:32:29  *** jarthur has quit IRC
5932018-11-28T20:33:03  *** bitcoin-git has joined #bitcoin-core-dev
5942018-11-28T20:33:04  <bitcoin-git> [bitcoin] practicalswift opened pull request #14829: travis: Enable functional tests in the ThreadSanitizer (TSan) build job (master...tsan) https://github.com/bitcoin/bitcoin/pull/14829
5952018-11-28T20:33:04  *** bitcoin-git has left #bitcoin-core-dev
5962018-11-28T20:35:20  <promag> another "An established connection was aborted by the software in your host machine" https://ci.appveyor.com/project/DrahtBot/bitcoin/builds/20621323
5972018-11-28T20:37:13  <instagibbs> huh, I'm not crazy, default debug flags were changed 9 months ago
5982018-11-28T20:37:28  <instagibbs> #13005
5992018-11-28T20:37:31  <gribble> https://github.com/bitcoin/bitcoin/issues/13005 | Make --enable-debug to pick better options by practicalswift · Pull Request #13005 · bitcoin/bitcoin · GitHub
6002018-11-28T20:37:47  <instagibbs> I find it *far* less useful for debugging
6012018-11-28T20:38:11  <instagibbs> --enable-super-serious-debug concept ACK ;P
6022018-11-28T20:40:33  *** elichai2 has quit IRC
6032018-11-28T20:43:28  <instagibbs> I will shut up about it now, with an issue open.
6042018-11-28T20:47:44  <instagibbs> #14380 ready for merge?
6052018-11-28T20:47:47  <gribble> https://github.com/bitcoin/bitcoin/issues/14380 | fix assert crash when specified change output spend size is unknown by instagibbs · Pull Request #14380 · bitcoin/bitcoin · GitHub
6062018-11-28T20:49:34  *** bitcoin-git has joined #bitcoin-core-dev
6072018-11-28T20:49:34  <bitcoin-git> [bitcoin] vim88 opened pull request #14831: Scripts and tools: Use #!/usr/bin/env bash instead of #!/bin/bash. (master...proper_shebang) https://github.com/bitcoin/bitcoin/pull/14831
6082018-11-28T20:49:34  *** bitcoin-git has left #bitcoin-core-dev
6092018-11-28T20:50:46  *** bitcoin-git has joined #bitcoin-core-dev
6102018-11-28T20:50:46  <bitcoin-git> [bitcoin] ch4ot1c opened pull request #14832: docs: Add more Doxygen information to Developer Notes (master...improvement/doxygen-docs) https://github.com/bitcoin/bitcoin/pull/14832
6112018-11-28T20:50:46  *** bitcoin-git has left #bitcoin-core-dev
6122018-11-28T20:54:00  *** promag has quit IRC
6132018-11-28T20:56:46  *** jarthur has joined #bitcoin-core-dev
6142018-11-28T20:58:40  *** Murch has quit IRC
6152018-11-28T20:58:54  *** bitcoin-git has joined #bitcoin-core-dev
6162018-11-28T20:58:55  <bitcoin-git> [bitcoin] MarcoFalke pushed 13 new commits to 0.17: https://github.com/bitcoin/bitcoin/compare/5150accdd2a7...9f556622c57d
6172018-11-28T20:58:55  <bitcoin-git> bitcoin/0.17 bb90695 gustavonalle: [wallet] Ensure wallet is unlocked before signing...
6182018-11-28T20:58:56  <bitcoin-git> bitcoin/0.17 85aacc4 Walter: Add autogen.sh in ARM Cross-compilation...
6192018-11-28T20:58:56  <bitcoin-git> bitcoin/0.17 9406502 Kaz Wesley: add a test demonstrating an overflow in a deserialization edge case...
6202018-11-28T20:58:57  *** bitcoin-git has left #bitcoin-core-dev
6212018-11-28T20:59:24  *** spinza has joined #bitcoin-core-dev
6222018-11-28T20:59:39  *** Murch has joined #bitcoin-core-dev
6232018-11-28T21:11:26  *** grubles has quit IRC
6242018-11-28T21:14:42  <BlueMatt> #14380 looks merge-able + backport-able
6252018-11-28T21:14:44  <gribble> https://github.com/bitcoin/bitcoin/issues/14380 | fix assert crash when specified change output spend size is unknown by instagibbs · Pull Request #14380 · bitcoin/bitcoin · GitHub
6262018-11-28T21:15:38  <BlueMatt> #14196 also looks merge-able (its against 0.17 and the upstream forward-port was merged)
6272018-11-28T21:15:40  <gribble> https://github.com/bitcoin/bitcoin/issues/14196 | [0.17][psbt] always drop the unnecessary utxo and convert non-witness utxo to witness when necessary by achow101 · Pull Request #14196 · bitcoin/bitcoin · GitHub
6282018-11-28T21:22:02  *** AaronvanW has quit IRC
6292018-11-28T21:31:53  *** intcat has quit IRC
6302018-11-28T21:32:13  *** EagleTM has joined #bitcoin-core-dev
6312018-11-28T21:32:33  *** AaronvanW has joined #bitcoin-core-dev
6322018-11-28T21:32:42  *** Murch has quit IRC
6332018-11-28T21:32:56  *** intcat has joined #bitcoin-core-dev
6342018-11-28T21:37:03  *** AaronvanW has quit IRC
6352018-11-28T21:37:19  *** jarthur has quit IRC
6362018-11-28T21:42:52  *** grubles has joined #bitcoin-core-dev
6372018-11-28T21:53:47  *** rex4539 has quit IRC
6382018-11-28T21:57:54  *** BB_ has joined #bitcoin-core-dev
6392018-11-28T22:00:43  *** BB_ has quit IRC
6402018-11-28T22:08:24  *** phwalkr has quit IRC
6412018-11-28T22:08:50  *** phwalkr has joined #bitcoin-core-dev
6422018-11-28T22:10:01  *** phwalkr_ has joined #bitcoin-core-dev
6432018-11-28T22:13:48  *** phwalkr has quit IRC
6442018-11-28T22:17:39  *** Murch has joined #bitcoin-core-dev
6452018-11-28T22:18:57  <dongcarl> I see that kallewoof has posted a few clang static analyzer reports on the repo... Wondering if there's any effort to have a bot that does this automatically or have CI integration for this...
6462018-11-28T22:20:55  *** EagleTM has quit IRC
6472018-11-28T22:24:20  *** spinza has quit IRC
6482018-11-28T22:27:08  *** Chris_Stewart_5 has quit IRC
6492018-11-28T22:27:22  *** spinza has joined #bitcoin-core-dev
6502018-11-28T22:33:26  *** AaronvanW has joined #bitcoin-core-dev
6512018-11-28T22:35:35  *** Chris_Stewart_5 has joined #bitcoin-core-dev
6522018-11-28T22:35:40  *** EagleTM has joined #bitcoin-core-dev
6532018-11-28T22:37:51  *** AaronvanW has quit IRC
6542018-11-28T22:49:10  *** shesek has joined #bitcoin-core-dev
6552018-11-28T22:49:10  *** shesek has joined #bitcoin-core-dev
6562018-11-28T23:08:51  *** EagleTM has quit IRC
6572018-11-28T23:19:40  *** rex4539 has joined #bitcoin-core-dev
6582018-11-28T23:20:29  *** Guyver2 has quit IRC
6592018-11-28T23:22:48  *** AaronvanW has joined #bitcoin-core-dev
6602018-11-28T23:24:21  *** EagleTM has joined #bitcoin-core-dev
6612018-11-28T23:24:22  *** grubles has left #bitcoin-core-dev
6622018-11-28T23:26:56  *** Chris_Stewart_5 has quit IRC
6632018-11-28T23:27:07  *** AaronvanW has quit IRC
6642018-11-28T23:35:20  <kallewoof> I thought practicalswift was our clang static analyzer bot
6652018-11-28T23:35:25  <kallewoof> Almost a joke :)
6662018-11-28T23:37:20  *** AaronvanW has joined #bitcoin-core-dev