12016-07-12T00:01:03  *** Giszmo has joined #bitcoin-core-dev
  22016-07-12T00:04:34  *** TomMc has quit IRC
  32016-07-12T00:05:52  *** Giszmo has quit IRC
  42016-07-12T00:06:57  *** Giszmo has joined #bitcoin-core-dev
  52016-07-12T00:28:09  *** AaronvanW has quit IRC
  62016-07-12T00:35:21  *** TomMc has joined #bitcoin-core-dev
  72016-07-12T00:53:22  *** Chris_Stewart_5 has quit IRC
  82016-07-12T00:56:22  *** Chris_Stewart_5 has joined #bitcoin-core-dev
  92016-07-12T01:02:52  *** belcher has quit IRC
 102016-07-12T01:08:54  *** Giszmo1 has joined #bitcoin-core-dev
 112016-07-12T01:09:06  *** Giszmo has quit IRC
 122016-07-12T01:10:24  *** Chris_Stewart_5 has quit IRC
 132016-07-12T01:15:46  *** Ylbam has quit IRC
 142016-07-12T01:30:43  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 152016-07-12T01:31:16  *** Lysander1 has joined #bitcoin-core-dev
 162016-07-12T01:34:25  *** Lysanders has quit IRC
 172016-07-12T01:39:27  *** xinxi has joined #bitcoin-core-dev
 182016-07-12T01:40:04  *** Giszmo1 has quit IRC
 192016-07-12T01:40:43  *** luke-jr has quit IRC
 202016-07-12T01:41:28  *** Giszmo has joined #bitcoin-core-dev
 212016-07-12T01:43:34  *** xinxi has quit IRC
 222016-07-12T01:48:39  *** TomMc has quit IRC
 232016-07-12T01:51:28  *** Giszmo has quit IRC
 242016-07-12T01:51:42  <phantomcircuit> fyi there's someone repeatedly connecting and disconnecting from a narrow ip range
 252016-07-12T01:51:43  <phantomcircuit> 2016-07-12 01:47:04.455787 receive version message: /bitcoinj:0.14.1/: version 70001, blocks=0, us=127.0.0.1:8333, peer=40824, peeraddr=37.97.164.230:60893
 262016-07-12T01:52:41  <phantomcircuit> 37.97.164.159
 272016-07-12T01:52:43  <phantomcircuit> 37.97.164.160
 282016-07-12T01:52:47  <phantomcircuit> 37.97.164.230
 292016-07-12T01:52:48  <phantomcircuit> 37.97.164.231
 302016-07-12T01:55:45  *** afk11 has quit IRC
 312016-07-12T01:56:34  *** afk11 has joined #bitcoin-core-dev
 322016-07-12T01:56:34  *** afk11 has quit IRC
 332016-07-12T01:56:34  *** afk11 has joined #bitcoin-core-dev
 342016-07-12T01:58:30  *** harrymm has quit IRC
 352016-07-12T02:12:12  *** harrymm has joined #bitcoin-core-dev
 362016-07-12T02:15:36  *** frankenmint has quit IRC
 372016-07-12T02:19:28  <Chris_Stewart_5> Can you receive messages on the p2p network from a non standard port? ie not 8333/18333
 382016-07-12T02:19:48  <Chris_Stewart_5> if I send a version message with the non standard port?
 392016-07-12T02:29:59  <sipa> yes
 402016-07-12T02:30:15  <sipa> but nodes strongly prefer connecting to nodes on the standard port
 412016-07-12T02:30:38  <sipa> they will pretty much only choose nodes with nonstandard ports if they have no other option
 422016-07-12T02:33:30  <dgenr8> good news. we don't have to worry too much that time-locked transactions could be delayed by 30 days by evil miners https://github.com/bitcoinxt/bitcoinxt/pull/142#issuecomment-231918519
 432016-07-12T02:34:55  *** frankenmint has joined #bitcoin-core-dev
 442016-07-12T02:39:43  *** fengling has quit IRC
 452016-07-12T02:40:07  *** fengling has joined #bitcoin-core-dev
 462016-07-12T02:44:52  *** whphhg has quit IRC
 472016-07-12T02:53:16  *** justanotheruser has quit IRC
 482016-07-12T02:55:32  *** justanotheruser has joined #bitcoin-core-dev
 492016-07-12T03:01:12  *** Chris_Stewart_5 has quit IRC
 502016-07-12T03:26:14  *** xinxi has joined #bitcoin-core-dev
 512016-07-12T03:29:12  <GitHub136> [bitcoin] dcousens opened pull request #8332: semi trivial: clarify witness branches in transaction.h serialization (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8332
 522016-07-12T03:31:34  *** xinxi has quit IRC
 532016-07-12T04:02:36  *** Alopex has quit IRC
 542016-07-12T04:03:41  *** Alopex has joined #bitcoin-core-dev
 552016-07-12T04:09:30  *** randy-waterhouse has joined #bitcoin-core-dev
 562016-07-12T04:11:14  <gmaxwell> dgenr8: uh. you realize that when you have .5 or more non-honest miners sustained, the existance of an honest blocks is purely their choice, right?  So that graph doesn't make a lot of sense.
 572016-07-12T04:12:05  <gmaxwell> yet again you have another negligently wrong security analysis, where you report 50% as absolutely safe, when in fact it's a guarenteed failure (assuming dedicated attackers)
 582016-07-12T04:16:25  *** luke-jr has joined #bitcoin-core-dev
 592016-07-12T04:16:43  <dgenr8> indeed, a 51% attack is a far greater threat than a blocktime slowdown, you get it
 602016-07-12T04:18:42  <gmaxwell> what? your analysis is just obviously broken on its face.
 612016-07-12T04:19:11  <gmaxwell> it claims that 80% dishonest mining is unable to slew the time.
 622016-07-12T04:20:05  <gmaxwell> This is obviously untrue, so you've make some obvious mistake-- if you have any result that isn't 100% at 50% hashpower.
 632016-07-12T04:23:16  <gmaxwell> And, what the heck is  "a 51% attack" -- Bitcoin exists as a confluence of incentives, one part of it is that even a user who buys up large amounts of hashpower for a brief period only gains the ability to reorganize recent transactions, which is difficult to profitably exploit at any scale-- which users can protect themselves from by waiting for additional confirmations.  Under the security mod
 642016-07-12T04:23:22  <gmaxwell> el change that you propose (and incorportated into your software without an adequate disclosure because you (based on the prior conversation) weren't actually aware of the implications,  miners that achieve a large amount (unclear how much but a majority is clearly sufficient) can add huge amounts of coins to themselves without any chain reorg and without even making a purchase.
 652016-07-12T04:25:36  <gmaxwell> (re obviously didn't understand, I'm referring to your prior claim that 100% hashpower and control over the user's clock was needed.)
 662016-07-12T04:26:31  <dgenr8> you read that statement completely wrong
 672016-07-12T04:28:53  <gmaxwell> K. Did I misunderstand that this was shipped out in XT without a release note pointing out the security model change; to a user community that obsesses over even minor softforks as taking away validation?
 682016-07-12T04:34:09  <gmaxwell> am I misreading your graph showing that a miner with 79% hashpower has a non-unity probablity of success at moving the timestamp back?
 692016-07-12T04:34:59  <dgenr8> XT, unlike core, would warn loudly as that 51% attack slowed the generation rate
 702016-07-12T04:35:26  <gmaxwell> Did I miss the fact that this whole design is just an insecure rip off of the proposal from this channel to use 30 days of _work_ at the current tip, as a gate on signature checks?
 712016-07-12T04:36:31  <gmaxwell> dgenr8: there is no need for the generation rate to slow significantly enough to trigger any warning that doesn't false positive constantly.
 722016-07-12T04:38:46  *** fengling has quit IRC
 732016-07-12T04:41:37  <dgenr8> the reason XT exists is that a few people cannot abide the choices you are making. it's too bad. for a while, folks worked together pretty well.
 742016-07-12T04:41:48  <dgenr8> you view the loss of talented people like gavin, jgarzik, and hearn as positve, and seek to utterly discredit others. but i'm OT
 752016-07-12T04:42:10  <gmaxwell> dgenr8: You are going to get some people robbed blind with this kind of sloppyness; it's a risk to our entire industry.
 762016-07-12T04:45:42  <gmaxwell> I don't have to do anything to discredit you (not to mention other people)-- you do so _yourself_; by shipping software to users that you don't even understand and being continually antagonistic to people who would otherwise help you avoid danger.
 772016-07-12T04:47:10  <dgenr8> Perhaps try again to manipulate the timestamp on testnet. Any hashing that sets timestamps correctly has a huge advantage though.
 782016-07-12T04:47:35  <gmaxwell> dgenr8: you didn't even notice the successful attack on testnet against classic then, I guess.
 792016-07-12T04:48:31  <dgenr8> i did see it was pushed it back a few days
 802016-07-12T04:49:17  <gmaxwell> A few days ago you seemed to be arguing that using the _miner provided_ timestamps on blocks to decide to bother validating the block or not would require 100% hashpower and control of the users local clock to exploit-- functionality you added without even adding a _release note_ to Bitcoin XT.  Your response to this being pointed out was to again repeat accusations that I backdoored your softwa
 812016-07-12T04:49:23  <gmaxwell> re. After having your mistaken understanding thrust on you; you've gone away and come back with another obviously broken misunderstanding; again radically overstating the security of this 'optimization'.
 822016-07-12T04:50:06  <gmaxwell> The only reason I even knew that XT and classic had incorporated this ill advised security change is because of people bragging about how much faster it synced. Yea, it's faster when you don't check 95% of the signautures, blindly...
 832016-07-12T04:51:05  <gmaxwell> So if you think you're going to make a war for node operation a war about who can make the most insecure software-- the stuff with the most tail risk of total failure, then hell yes I'm going to call that out. And you should be thankful that I've taken the concerns directly to you,  and not-- like other people in your community-- gone straight to the press with them.
 842016-07-12T04:51:36  <gmaxwell> (Especially when it's so easy to demonstrate the exploit on a live network)
 852016-07-12T04:53:15  <dgenr8> hmm. i think this whole display is for the benefit of third parties. anyhow i disagree on the degree of risk, but that's not to say the regular checkpoints couldn't come back or that the default selection could even change. but that belongs to a rational discussion we're not having
 862016-07-12T04:53:38  <gmaxwell> Fair enough.
 872016-07-12T04:55:23  <dgenr8> my concern with your thin blocks change was not that it made it to XT briefly.  it was that you removed the thin blocks functionality from core users.
 882016-07-12T04:56:36  <gmaxwell> I'm sorry for being such a dick on this. I do really think that the blockheader based skipping validation is a race to the bottom-- who can provide the worst security (for the fastest performance), to hell with the consequences (and no one adequately disclosing it).  It doesn't help that a much better way of doing the same thing was already proposed in Core; and to me it seems like pure NIH to i
 892016-07-12T04:56:42  <gmaxwell> mplement a much riskier version.
 902016-07-12T04:58:35  <gmaxwell> dgenr8: I had no idea that it had any impact there, hell, the change was actually motivated by a complaint you made about the behavior (which, since you didn't disclose, I didn't know it was due to the prior limit of 1000 breaking mike's thinblocks). I didn't even initially use the bloom filter until wumpus and pieter beat me down on the memory usage.  And ultimately since there was _no_ reliabl
 912016-07-12T04:58:41  <gmaxwell> e mechenism to request transactions that were already in a block (an observation we made on that approach in 2013), mike's way of doing it couldn't have been reliable.
 922016-07-12T04:58:51  *** xinxi has joined #bitcoin-core-dev
 932016-07-12T04:59:11  <gmaxwell> I also explained this previously, but you seem even more insistant on assuming bad faith on my part than I am on seeing you as a fool. :)
 942016-07-12T05:00:44  <gmaxwell> Seriously, if I wanted to 'backdoor' your software, the avenues available are far more profound-- your response has made me profoundly uncomfortable with the continued existance of Bitcoin XT-- you'll continue to copy code from Core, and when the inevitable errors that happen from interactions which I could never have anticiapted; you've shown that you'll accuse me of unethical or even criminal
 952016-07-12T05:00:50  <gmaxwell> conduct.
 962016-07-12T05:02:26  <gmaxwell> s/blockheader based/blockheader timestamp based/  to be more clear. the earlier proposal of using total work instead of timestamps, is much more appealing.
 972016-07-12T05:03:35  <dgenr8> whoa slow down ... the map size problem I found had nothing to do with thin blocks, which is why i was eager to copy your fix for it
 982016-07-12T05:04:29  <gmaxwell> dgenr8: I thought (after trying to figure out why you even copied the change) the reason you commented on the map size is because with thinblocks the small map meant the far end had no idea that you had most of the transactions you already had, then sent redundant stuff.
 992016-07-12T05:04:51  <dgenr8> no, i found it while looking at some other core PR
1002016-07-12T05:05:33  <gmaxwell> then why did you even assume I was trying to screw up your thinblocks stuff?  I don't believe I had _any_ idea XT was even screwing with that at that time.
1012016-07-12T05:06:11  <gmaxwell> (I wouldn't have assumed it because the patch mike had was so obviously junk-- handling it in the ping handler, no way to cope with missing transactions except praying that they were still in the relay cache)
1022016-07-12T05:06:18  <dgenr8> if you recall that effect was found independently weeks later by Peter Tschipper
1032016-07-12T05:06:51  <dgenr8> its all irrelevant now anyway
1042016-07-12T05:07:00  *** xinxi has quit IRC
1052016-07-12T05:07:27  <gmaxwell> in any case, indeed it broke the thin block stuff completely; then you merged it, and released a new version with it and the initial release of that thinblock stuff--- meaning you hadn't even tested it for basic functionality; which is basically terrifying from my perspective.
1062016-07-12T05:07:41  <gmaxwell> You can't deny that the commit message was scream loud totally clear about _exactly_ what the change did.
1072016-07-12T05:08:35  <gmaxwell> and so how the hell can I defend myself against bad testing on your part?  I made a very very clearly described change, which you didn't comment on, integrated so it broke your stuff totally, then claimed misconduct on my part. Thats seriously bad mojo.
1082016-07-12T05:08:35  <dgenr8> it went to master, not a release.  please don't put 'backdoor' in quotes as I never said that word and as I said, that was not my concern
1092016-07-12T05:08:56  *** xinxi has joined #bitcoin-core-dev
1102016-07-12T05:11:37  <gmaxwell> that was certantly what people extracted from your comments, https://www.reddit.com/r/bitcoinxt/comments/43jgtt/blockstream_engineers_maxwell_and_wuille_caught/
1112016-07-12T05:12:17  <gmaxwell> Though indeed, I guess you only use the words "your sneak attack" and not "backdoor" yourself.
1122016-07-12T05:16:24  *** kadoban has quit IRC
1132016-07-12T05:16:44  *** kadoban has joined #bitcoin-core-dev
1142016-07-12T05:19:14  <gmaxwell> and "Here we have Blockstream actively fighting scaling improvements"   (and not to mention misrepresentation the that change was to avoid a one in a million false positive, when the chance happens for every txn indpendantly, so after seeing just 10k txn the chance is 1%.)
1152016-07-12T05:27:48  *** xinxi_ has joined #bitcoin-core-dev
1162016-07-12T05:27:48  *** xinxi has quit IRC
1172016-07-12T05:29:46  <gmaxwell> XT v0.11E appears to contain the setinventory known and 'thinblock' change; but now looking at it I see you left it probablistically screwing over spv clients.
1182016-07-12T05:30:09  <eragmus> gmaxwell: Why are you wasting your precious time with a dgenr8 like him? :) Or, at least, maybe charge him and the others by the minute for this consulting.
1192016-07-12T05:30:14  <gmaxwell> I wonder how many bitcoins will be lost by people throwing out wallets that look empty but arn't. :(
1202016-07-12T05:31:01  <eragmus> dgenr8: Btw, you should be careful before making everyone laugh so much -- "the loss of talented people like gavin, jgarzik, and hearn" -- I nearly choked. I might have to bill you for any potential hospital expenses.
1212016-07-12T05:31:19  *** fengling has joined #bitcoin-core-dev
1222016-07-12T05:32:07  <gmaxwell> eragmus: (1) because software that silently downgrades security then promotes itself as faster is a risk to the continued viability and value of Bitcoin, which I care about. .. and because he attacks me by claiming that I've acted unethically, which if left unchallenged ends up recycled as accepted truth in places like the NYT where it can cause me lifelong harm.
1232016-07-12T05:32:16  *** cryptapus_ has joined #bitcoin-core-dev
1242016-07-12T05:32:16  *** cryptapus_ has joined #bitcoin-core-dev
1252016-07-12T05:33:55  <wumpus> PSA: this channel is about bitcoin core development, XT and classic and certainly non-technical drama around them are very off-topic
1262016-07-12T05:37:27  <phantomcircuit> indeed wumpus is right, possibly this could move to #bitcoin
1272016-07-12T05:38:02  <phantomcircuit> wumpus, fyi you might find this interesting https://github.com/bitcoin/bitcoin/issues/8333
1282016-07-12T05:38:55  <dgenr8> gmaxwell: breadwallet already detects the condition and corrects it by reconnecting
1292016-07-12T05:41:08  <wumpus> phantomcircuit: in what world is 31.87ms slow, I mean, I've seen logs in where validation took that *per txin* :)
1302016-07-12T05:43:07  <phantomcircuit> wumpus, in a world where i can mess with settings and have an average block validate in 30ms
1312016-07-12T05:43:18  <phantomcircuit> thanks to my 8GiB sigcache and 16GiB dbcache
1322016-07-12T05:43:33  <phantomcircuit> (and a hack that loads the entire utxo into cache on start)
1332016-07-12T05:44:40  <gmaxwell> wumpus: he's optimizing mining overheads, some of them are harder to address than bitcoind behavior. :)  (e.g. cannot decrease the radius of the earth :P )
1342016-07-12T05:44:59  <wumpus> phantomcircuit: anyhow to say more about it we
1352016-07-12T05:45:06  <wumpus> 'd need detailed profiling of that step
1362016-07-12T05:46:35  <phantomcircuit> gmaxwell, im working on that, i have a plan to drill down and around the mantle
1372016-07-12T05:46:44  <phantomcircuit> i only need a few trillion dollars
1382016-07-12T05:47:23  *** xinxi_ has quit IRC
1392016-07-12T05:47:47  <gmaxwell> /msg phantomcircuit has the patent issued yet for the neutrion based transciever yet?
1402016-07-12T05:49:29  <wumpus> gmaxwell: yes can only get as close as possible to the physical limit
1412016-07-12T05:50:11  *** xinxi has joined #bitcoin-core-dev
1422016-07-12T05:52:46  <gmaxwell> wumpus: there are a number of things that aren't the physical limits but are still harder to speedup than core, also at least as long as validation is in the relay critical path, any part of validation adds up as the node count increases. Though thats probably better fixed by getting validation out of the critcial path for relay to other full nodes.
1432016-07-12T05:55:02  *** xinxi has quit IRC
1442016-07-12T06:02:52  <wumpus> gmaxwell: what kind of things, optimizing the P2P protocol? network infrastructure?
1452016-07-12T06:04:49  <wumpus> as long as any part of validation is the bottleneck, optimizing that is still part of 'speeding up core'
1462016-07-12T06:07:00  <wumpus> if validation is out of the critical part all that is left is the network, where the random P2P network isn't the most efficient structure for propagating something around the world quickly
1472016-07-12T06:09:23  <wumpus> (but that's what the relay network is for)
1482016-07-12T06:21:36  *** Yv7trNY has joined #bitcoin-core-dev
1492016-07-12T06:24:41  *** Yv7trNY has quit IRC
1502016-07-12T06:26:27  *** xinxi has joined #bitcoin-core-dev
1512016-07-12T06:27:33  *** davidlj95 has joined #bitcoin-core-dev
1522016-07-12T06:37:12  <sipa> phantomcircuit: it's good to see that part of the logic becoming measurable :)
1532016-07-12T06:38:21  <sipa> phantomcircuit: it would be nice if you could see if the two PRs i referenced on your issue affect that number
1542016-07-12T06:47:32  *** xinxi has quit IRC
1552016-07-12T06:48:28  *** Ylbam has joined #bitcoin-core-dev
1562016-07-12T06:53:52  *** cryptapus_ has quit IRC
1572016-07-12T06:57:45  *** xinxi has joined #bitcoin-core-dev
1582016-07-12T07:22:28  *** whphhg has joined #bitcoin-core-dev
1592016-07-12T07:30:28  *** kadoban has quit IRC
1602016-07-12T07:38:13  *** frankenmint has quit IRC
1612016-07-12T07:38:42  *** frankenmint has joined #bitcoin-core-dev
1622016-07-12T07:49:42  *** jtimon has joined #bitcoin-core-dev
1632016-07-12T07:54:08  *** murch has joined #bitcoin-core-dev
1642016-07-12T07:58:23  *** DigiByteDev has joined #bitcoin-core-dev
1652016-07-12T08:15:04  *** tucenaber has quit IRC
1662016-07-12T08:16:11  *** Alopex has quit IRC
1672016-07-12T08:17:17  *** Alopex has joined #bitcoin-core-dev
1682016-07-12T08:24:11  *** Alopex has quit IRC
1692016-07-12T08:25:30  *** xinxi has quit IRC
1702016-07-12T08:34:04  *** asoltys has quit IRC
1712016-07-12T08:37:23  *** xinxi has joined #bitcoin-core-dev
1722016-07-12T08:38:31  *** xinxi has quit IRC
1732016-07-12T08:40:34  *** asoltys has joined #bitcoin-core-dev
1742016-07-12T08:49:48  *** jannes has joined #bitcoin-core-dev
1752016-07-12T08:53:40  *** tucenaber has joined #bitcoin-core-dev
1762016-07-12T08:53:59  *** tucenaber has joined #bitcoin-core-dev
1772016-07-12T08:58:17  *** whphhg_ has joined #bitcoin-core-dev
1782016-07-12T09:01:07  *** whphhg has quit IRC
1792016-07-12T09:06:42  *** DigiByteDev has quit IRC
1802016-07-12T09:07:26  *** fengling has quit IRC
1812016-07-12T09:12:07  *** mkarrer has joined #bitcoin-core-dev
1822016-07-12T09:12:48  *** mkarrer has joined #bitcoin-core-dev
1832016-07-12T09:20:16  *** ebfull has joined #bitcoin-core-dev
1842016-07-12T09:23:26  *** whphhg_ is now known as whphhg
1852016-07-12T09:25:57  *** randy-waterhouse has quit IRC
1862016-07-12T09:45:37  *** frankenmint has quit IRC
1872016-07-12T09:47:22  <GitHub97> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/4831a16223dbb42da3091e616c47eeb01f53f73b
1882016-07-12T09:47:22  <GitHub97> bitcoin/master 4831a16 Wladimir J. van der Laan: qt: periodic translation update...
1892016-07-12T09:49:18  *** moli has quit IRC
1902016-07-12T09:55:05  *** jtimon has quit IRC
1912016-07-12T09:57:28  *** laurentmt has joined #bitcoin-core-dev
1922016-07-12T09:57:33  *** mkarrer has quit IRC
1932016-07-12T10:00:34  *** moli has joined #bitcoin-core-dev
1942016-07-12T10:02:49  *** mkarrer has joined #bitcoin-core-dev
1952016-07-12T10:03:24  *** go1111111 has quit IRC
1962016-07-12T10:09:34  *** mkarrer has quit IRC
1972016-07-12T10:12:15  *** mkarrer has joined #bitcoin-core-dev
1982016-07-12T10:17:07  *** davidlj95 has left #bitcoin-core-dev
1992016-07-12T10:27:29  *** xinxi has joined #bitcoin-core-dev
2002016-07-12T10:33:39  *** AaronvanW has joined #bitcoin-core-dev
2012016-07-12T10:33:39  *** AaronvanW has joined #bitcoin-core-dev
2022016-07-12T10:34:33  *** fengling has joined #bitcoin-core-dev
2032016-07-12T10:39:26  *** fengling has quit IRC
2042016-07-12T10:54:52  <GitHub74> [bitcoin] kholbekj opened pull request #8335: update inline copyright notices (master...update-inline-copyright) https://github.com/bitcoin/bitcoin/pull/8335
2052016-07-12T10:55:03  *** Giszmo has joined #bitcoin-core-dev
2062016-07-12T11:05:26  *** arubi has quit IRC
2072016-07-12T11:06:06  *** arubi has joined #bitcoin-core-dev
2082016-07-12T11:07:58  *** Giszmo has quit IRC
2092016-07-12T11:11:34  *** Giszmo has joined #bitcoin-core-dev
2102016-07-12T11:20:31  *** Giszmo has quit IRC
2112016-07-12T11:31:28  *** jtimon has joined #bitcoin-core-dev
2122016-07-12T11:35:11  *** moli has quit IRC
2132016-07-12T11:36:14  *** fengling has joined #bitcoin-core-dev
2142016-07-12T11:41:06  *** fengling has quit IRC
2152016-07-12T11:54:47  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2162016-07-12T11:57:02  *** arubi has quit IRC
2172016-07-12T11:57:22  <GitHub72> [bitcoin] jonasschnelli closed pull request #8335: update inline copyright notices (master...update-inline-copyright) https://github.com/bitcoin/bitcoin/pull/8335
2182016-07-12T11:57:39  *** arubi has joined #bitcoin-core-dev
2192016-07-12T11:59:47  *** laurentmt has quit IRC
2202016-07-12T12:06:52  *** YOU-JI has joined #bitcoin-core-dev
2212016-07-12T12:17:52  *** Chris_Stewart_5 has quit IRC
2222016-07-12T12:27:52  *** jannes has quit IRC
2232016-07-12T12:36:37  *** arubi has quit IRC
2242016-07-12T12:37:46  *** fengling has joined #bitcoin-core-dev
2252016-07-12T12:39:33  *** jannes has joined #bitcoin-core-dev
2262016-07-12T12:42:26  *** fengling has quit IRC
2272016-07-12T12:50:05  *** arubi has joined #bitcoin-core-dev
2282016-07-12T12:58:38  *** G1lius has joined #bitcoin-core-dev
2292016-07-12T13:15:26  *** arubi has quit IRC
2302016-07-12T13:16:16  *** arubi has joined #bitcoin-core-dev
2312016-07-12T13:22:58  *** JackH has quit IRC
2322016-07-12T13:34:11  *** TomMc has joined #bitcoin-core-dev
2332016-07-12T13:35:39  *** YOU-JI has quit IRC
2342016-07-12T13:39:07  *** GreenIsMyPepper has quit IRC
2352016-07-12T13:39:16  *** fengling has joined #bitcoin-core-dev
2362016-07-12T13:41:07  *** GreenIsMyPepper has joined #bitcoin-core-dev
2372016-07-12T13:44:06  *** fengling has quit IRC
2382016-07-12T13:53:00  *** Guyver2 has joined #bitcoin-core-dev
2392016-07-12T13:53:42  *** zooko has joined #bitcoin-core-dev
2402016-07-12T13:55:25  *** lysobit- has joined #bitcoin-core-dev
2412016-07-12T13:56:27  *** GreenIsMyPepper has quit IRC
2422016-07-12T13:56:55  *** musalbas- has joined #bitcoin-core-dev
2432016-07-12T14:01:03  *** kadoban has joined #bitcoin-core-dev
2442016-07-12T14:01:18  *** baldur has quit IRC
2452016-07-12T14:10:11  *** GreenIsMyPepper has joined #bitcoin-core-dev
2462016-07-12T14:12:33  *** dgenr8 has quit IRC
2472016-07-12T14:13:30  *** dgenr8 has joined #bitcoin-core-dev
2482016-07-12T14:15:43  *** BCBot has quit IRC
2492016-07-12T14:18:39  *** fifth_ has joined #bitcoin-core-dev
2502016-07-12T14:18:55  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2512016-07-12T14:26:39  *** moli has joined #bitcoin-core-dev
2522016-07-12T14:27:01  <michagogo> Has anyone looked into packaging Bitcoin Core into a snap?
2532016-07-12T14:27:11  <michagogo> (Ubuntu's new packaging format)
2542016-07-12T14:27:16  *** murch has quit IRC
2552016-07-12T14:28:24  <michagogo> I haven't gotten a chance to look at it closely (and I don't know if I'd really understand it), but it sounds like it's an Ubuntu-supported way for devs to package apps in self-contained packages that can update independently of the distro
2562016-07-12T14:29:05  <michagogo> Which sounds like it would solve a lot of the problems we've had with Bitcoin being packaged in the Ubuntu repos
2572016-07-12T14:29:38  <michagogo> (i.e. it _might_ let us sanely get Bitcoin Core into Ubuntu)
2582016-07-12T14:29:54  <sipa> sounds interesting
2592016-07-12T14:31:15  *** moli has quit IRC
2602016-07-12T14:32:51  *** moli has joined #bitcoin-core-dev
2612016-07-12T14:39:30  <jonasschnelli> sounds good... the current PPA is maintained by thebluematt, maybe he's interested
2622016-07-12T14:40:48  *** fengling has joined #bitcoin-core-dev
2632016-07-12T14:45:46  *** fengling has quit IRC
2642016-07-12T15:01:45  *** Chris_Stewart_5 has quit IRC
2652016-07-12T15:05:12  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2662016-07-12T15:15:45  *** GreenIsMyPepper has quit IRC
2672016-07-12T15:17:45  *** GreenIsMyPepper has joined #bitcoin-core-dev
2682016-07-12T15:22:15  *** GreenIsMyPepper has quit IRC
2692016-07-12T15:23:03  *** fifth_ has quit IRC
2702016-07-12T15:25:16  *** GreenIsMyPepper has joined #bitcoin-core-dev
2712016-07-12T15:47:14  *** laurentmt has joined #bitcoin-core-dev
2722016-07-12T16:33:42  *** Chris_Stewart_5 has quit IRC
2732016-07-12T16:35:28  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2742016-07-12T16:44:28  *** fengling has joined #bitcoin-core-dev
2752016-07-12T16:49:06  *** fengling has quit IRC
2762016-07-12T16:56:20  *** G1lius has quit IRC
2772016-07-12T16:59:18  *** spudowiar has joined #bitcoin-core-dev
2782016-07-12T17:33:56  *** jannes has quit IRC
2792016-07-12T17:45:25  *** fengling has joined #bitcoin-core-dev
2802016-07-12T17:48:43  *** Chris_Stewart_5 has quit IRC
2812016-07-12T17:50:06  *** fengling has quit IRC
2822016-07-12T17:54:28  *** paveljanik has joined #bitcoin-core-dev
2832016-07-12T18:03:38  <xinxi> I've herd there is slack group for Bitcoin core dev. Who can tell me the URL?
2842016-07-12T18:07:16  <btcdrak> xinxi: slack.bitcoincore.org
2852016-07-12T18:07:31  <eragmus> xinxi: https://slack.bitcoincore.org -- However, it is not really focused on Core development. It's a general purpose community with nearly 2,000 members who discuss all manner of topics.
2862016-07-12T18:07:34  <btcdrak> but it's more a community slack.
2872016-07-12T18:07:53  <xinxi> thank you.
2882016-07-12T18:15:16  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2892016-07-12T18:16:29  <xinxi> Oh, messages sent on slack cannot be seen here.
2902016-07-12T18:16:41  *** spudowiar has quit IRC
2912016-07-12T18:20:00  <Chris_Stewart_5> Is there some weird semantics with TransactionMessage on the p2p network that are different than BlockMessage? Besides switching MsgBlock to MsgTx
2922016-07-12T18:20:14  <Chris_Stewart_5> I keep getting a NotFound message response, when I know the tx exists
2932016-07-12T18:20:34  <sipa> Chris_Stewart_5: you can't just request any transaction
2942016-07-12T18:20:47  <sipa> only things that have been advertized to you
2952016-07-12T18:21:29  <sipa> (reasons for this are 1) there is no full index for all transactions in the chain 2) there is a privacy leak if you allow peers to check whether you have seen a particular transaction already)
2962016-07-12T18:22:52  *** adamg has quit IRC
2972016-07-12T18:23:31  <Chris_Stewart_5> so what does -reindex allows you to easily search by header id then? And can you elaborate more on 2)? Does that allow them withold honest txs from you if you are being sybil attacked?
2982016-07-12T18:24:13  <sipa> Chris_Stewart_5: the network tries to hide where a transaction originates
2992016-07-12T18:24:36  <sipa> for that, transactions are relayed with random delays between them, and in different order for different peers
3002016-07-12T18:25:07  <sipa> if i could query whether you have a transaction that i know about, but you haven't told me about, i can bypass that mechanism
3012016-07-12T18:25:40  <sipa> Chris_Stewart_5: -reindex just throws away the database and builds a new one
3022016-07-12T18:25:50  <Chris_Stewart_5> Sorry i meant -txindex
3032016-07-12T18:25:57  <sipa> yes, that's for local consumption
3042016-07-12T18:26:01  <sipa> not exposed to the network
3052016-07-12T18:26:20  *** adamg has joined #bitcoin-core-dev
3062016-07-12T18:26:55  <Chris_Stewart_5> Ok. So if I am understanding you correctly we allow arbitrary block querying because 1.) we need it to sync nodes on the network, 2.) You can't tell where a tx originates from once it is included in the block
3072016-07-12T18:27:22  <Chris_Stewart_5> What file is the code in wrt to transaction propogation? main.cpp? net.cpp?
3082016-07-12T18:27:27  <sipa> both
3092016-07-12T18:32:14  <Chris_Stewart_5> sipa: Is this section in the developer reference wrong then? Under the heading 'Transaction response' https://bitcoin.org/en/developer-reference#tx
3102016-07-12T18:32:46  <sipa> no
3112016-07-12T18:32:46  <Chris_Stewart_5> I interpreted it as you build a getdata message, send it and then get a tx message response
3122016-07-12T18:33:04  <sipa> it could be clarified
3132016-07-12T18:33:23  <sipa> but it's not wrong that a tx is sent as response to getdata TX
3142016-07-12T18:34:11  <sipa> but i agree it's a bit misleading
3152016-07-12T18:34:30  <Chris_Stewart_5> sipa: With the caveat being that the node has already broadcasted the txid to that node requesting the tx with a getdata right?
3162016-07-12T18:37:08  <sipa> or through the bip35 mempool command
3172016-07-12T18:38:41  <Chris_Stewart_5> gotcha, thanks.
3182016-07-12T18:40:13  <sipa> also, after relay, you only have a finite amount of time to getdata
3192016-07-12T18:40:20  <sipa> i think 15 minutes by default
3202016-07-12T18:42:08  <Chris_Stewart_5> Seems like that could have interesting consequences if the hash rate where to suddenly drop significantly. Tx propogation could stagnate couldn't it?
3212016-07-12T18:42:29  <sipa> tx propagation has nothing to do with blocks
3222016-07-12T18:46:21  <Chris_Stewart_5> True, I guess the scenario I was envisioning in my head would only happen if nodes were constantly being shut off and turned on at an alarming rate
3232016-07-12T18:46:56  *** fengling has joined #bitcoin-core-dev
3242016-07-12T18:49:07  *** gitju has joined #bitcoin-core-dev
3252016-07-12T18:50:11  *** gitju has left #bitcoin-core-dev
3262016-07-12T18:51:46  *** fengling has quit IRC
3272016-07-12T19:01:03  *** Chris_Stewart_5 has quit IRC
3282016-07-12T19:09:45  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3292016-07-12T19:14:11  *** Chris_Stewart_5 has quit IRC
3302016-07-12T19:17:21  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3312016-07-12T19:25:03  *** ryan`c has joined #bitcoin-core-dev
3322016-07-12T19:29:31  *** owowo has quit IRC
3332016-07-12T19:30:59  *** ryan`c has quit IRC
3342016-07-12T19:35:49  *** ryan`c has joined #bitcoin-core-dev
3352016-07-12T19:37:40  *** Chris_Stewart_5 has quit IRC
3362016-07-12T19:45:26  *** ryan-c has quit IRC
3372016-07-12T19:46:21  *** ryan`c is now known as ryan-c
3382016-07-12T19:48:29  *** fengling has joined #bitcoin-core-dev
3392016-07-12T19:53:26  *** fengling has quit IRC
3402016-07-12T19:54:09  *** owowo has joined #bitcoin-core-dev
3412016-07-12T19:55:30  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3422016-07-12T19:55:33  *** go1111111 has joined #bitcoin-core-dev
3432016-07-12T19:56:18  *** frankenmint has joined #bitcoin-core-dev
3442016-07-12T19:56:20  *** JackH has joined #bitcoin-core-dev
3452016-07-12T20:02:52  <bsm117532> My transactions spending segwit outputs are being rejected by sendrawtransaction...
3462016-07-12T20:03:10  <sipa> what code?
3472016-07-12T20:03:20  <bsm117532> Do I understand correctly that it's normal behavior for the segwit input scripts have a leftover element on the stack?
3482016-07-12T20:03:31  <sipa> indeed
3492016-07-12T20:03:53  <bsm117532> 64: non-mandatory-script-verify-flag (Script evaluated without error but finished with a false/empty top stack element)
3502016-07-12T20:04:19  <bsm117532> The transaction is https://www.zerobin.net/?d2c7842e69b63293#PUa9xa3YL9B3N2dwSlbcmfLVMSxyeaUvWJ4YLtp9cEQ=
3512016-07-12T20:04:26  <sipa> that likely means your signature is incorrect
3522016-07-12T20:04:31  <bsm117532> Hmmm ok
3532016-07-12T20:09:52  *** frankenmint has quit IRC
3542016-07-12T20:10:41  <bsm117532> I tried to create a spend of a P2WPKH transaction, with the signature and pubkey as the two elements in the witness data.  But signrawtransaction is giving me a txinwitness that contains a signature and a 65 byte-blob.  Is this second value an uncompressed pubkey or something?
3552016-07-12T20:17:09  *** Chris_Stewart_5 has quit IRC
3562016-07-12T20:19:36  <bsm117532> Here's a decoding of a segwit spend generated by sendrawtransaction and one by me: https://www.zerobin.net/?9964fec796427a47#3Y2hZLaVTUV03Qx+vEG7i0NYtiDdhVAnM/BE5tEIXFI=
3572016-07-12T20:20:06  <bsm117532> Can someone explain the difference in what sendrawtransaction is putting as the second element of the witness data?
3582016-07-12T20:20:30  <sipa> yup, that looks like an uncompressed pubkey
3592016-07-12T20:21:07  <bsm117532> Are uncompressed pubkeys required?  AFAICT that's the only difference between the two.
3602016-07-12T20:21:15  <sipa> no
3612016-07-12T20:21:32  <sipa> they're even discouraged and no modern bitcoin core wallet will use them by default
3622016-07-12T20:21:57  <sipa> but if you have a very old wallet file or have imported uncompressed keys, there is no choice
3632016-07-12T20:22:07  <sipa> *won't use them by default
3642016-07-12T20:23:01  <bsm117532> Ok so if sendrawtransaction is using uncompressed pubkeys, it could be a bug, and if segwit script validation is rejecting compressed pubkeys, it could be a bug...I'll dig.
3652016-07-12T20:23:21  <sipa> i can guarantee you that compressed pubkeys work
3662016-07-12T20:23:35  <sipa> i suspect that you're just signing the incorrect signature hash
3672016-07-12T20:24:04  <bsm117532> That's entirely possible.
3682016-07-12T20:24:23  <sipa> (that's just from experience of other people seeing fail there)
3692016-07-12T20:25:17  <bsm117532> Ok I'll dig there first.  But I'm also working on a wallet-functionality patch for core.  My node shouldn't be generating uncompressed pubkeys, though I do run --with-incompatible-bdb, other than that all keys should be new.
3702016-07-12T20:25:36  <sipa> did you import keys, ever?
3712016-07-12T20:27:01  *** belcher has joined #bitcoin-core-dev
3722016-07-12T20:28:38  <bsm117532> Hmmm...possibly.
3732016-07-12T20:28:51  <bsm117532> Should I recreate my wallet then?
3742016-07-12T20:29:10  <sipa> imported keys have a flag that says whether the corresponding pubkey is to compressed or not (otherwise the address is not well defined)
3752016-07-12T20:29:20  <sipa> i wouldn't bother
3762016-07-12T20:29:45  <bsm117532> Hmm maybe I just got unlucky with the chosen input.
3772016-07-12T20:29:51  *** zooko has quit IRC
3782016-07-12T20:32:13  * bsm117532 beats on BIP 143.  I knew it was unlikely that my sighash was correct...
3792016-07-12T20:42:42  * bsm117532 sees now...BIP 143 isn't even remotely close to the pre-segwit algorithm.
3802016-07-12T20:43:14  <sipa> nope
3812016-07-12T20:43:56  <sipa> it's still more or less the same order of data, but all 'over all inputs' or 'over all outputs' things are first aggregated into an intermediary hash
3822016-07-12T20:43:59  <bsm117532> In my defense, I wrote in the python-bitcoinlib PR that I didn't implement this yet!  ;-)
3832016-07-12T20:50:03  *** fengling has joined #bitcoin-core-dev
3842016-07-12T20:54:46  *** fengling has quit IRC
3852016-07-12T21:01:10  <bsm117532> In BIP 143, this line:   if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) {
3862016-07-12T21:01:25  <bsm117532> Isn't it simpler to just say: if(nHashType | SIGHASH_ALL)  ?
3872016-07-12T21:02:28  <bsm117532> errr.... if(nHashType & SIGHASH_ALL)
3882016-07-12T21:04:23  <sipa> that would not be the same, i think?
3892016-07-12T21:05:00  <bsm117532> I think it's the same unless there are more than 4 SIGHASH_* types
3902016-07-12T21:07:53  <sipa> there are 6 combinations
3912016-07-12T21:08:08  <sipa> but the sighash byte can have 256 values
3922016-07-12T21:08:38  <sipa> all of which map to one of those 6 formulas
3932016-07-12T21:10:27  *** Guyver2 has quit IRC
3942016-07-12T21:11:41  <bsm117532> I see.  I thought it was just a bitmap.
3952016-07-12T21:12:11  <bsm117532> Reference implementation is easy to translate to python, I'll stop trying to "improve" it.  ;-)
3962016-07-12T21:14:03  <sipa> https://github.com/bitcoin/bitcoin/blob/master/qa/rpc-tests/test_framework/script.py#L908
3972016-07-12T21:15:34  <bsm117532> Thanks!
3982016-07-12T21:17:37  *** Avinty-L_ has joined #bitcoin-core-dev
3992016-07-12T21:18:58  <bsm117532> Sorry I hadn't realized this was so close to petertodd's repo.
4002016-07-12T21:19:02  * bsm117532 diffs.
4012016-07-12T21:19:50  <sipa> i think it forked off a long time ago
4022016-07-12T21:20:06  <sipa> it's a forked, stripped, and then extended version just for tests
4032016-07-12T21:20:46  <bsm117532> makes sense.
4042016-07-12T21:24:17  *** bustd_soket has quit IRC
4052016-07-12T21:25:31  *** spudowiar has joined #bitcoin-core-dev
4062016-07-12T21:25:39  <sipa> but feel free to steal/donate code of course
4072016-07-12T21:25:59  <bsm117532> Thanks, I'll attribute what I steal.
4082016-07-12T21:26:02  *** jtimon has quit IRC
4092016-07-12T21:32:55  *** laurentmt has quit IRC
4102016-07-12T21:35:26  *** Avinty-L_ has quit IRC
4112016-07-12T21:36:54  *** bustd_soket has joined #bitcoin-core-dev
4122016-07-12T21:37:47  *** Avinty_L_ has joined #bitcoin-core-dev
4132016-07-12T21:43:12  *** TomMc has quit IRC
4142016-07-12T21:45:38  *** Avinty_L_ has joined #bitcoin-core-dev
4152016-07-12T21:47:16  *** Avinty_L_ has quit IRC
4162016-07-12T21:51:33  *** fengling has joined #bitcoin-core-dev
4172016-07-12T21:56:25  *** TomMc has joined #bitcoin-core-dev
4182016-07-12T21:56:26  *** fengling has quit IRC
4192016-07-12T22:09:19  *** Avinty_L has joined #bitcoin-core-dev
4202016-07-12T22:13:55  *** Avinty_L has quit IRC
4212016-07-12T22:17:41  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4222016-07-12T22:24:17  <midnightmagic> sipa (or anyone really): When a node hears about a sibling block to its current valid head, it ignores it, correct? Or does it hold it until it discovers which fork the miners settle on?
4232016-07-12T22:24:55  <midnightmagic> I thought it sits on it so long as it is also valid and does not represent less work than the current head?
4242016-07-12T22:28:23  <bsm117532> midnightmagic: It's my understanding that it doesn't *relay* it, but does track its chain tip, in case its PoW becomes larger.
4252016-07-12T22:41:40  *** arubi has quit IRC
4262016-07-12T22:51:49  <sipa> midnightmagic: we keep track of the headers
4272016-07-12T22:52:06  <sipa> midnightmagic: but only actively try to fetch the blocks if they're overtaking our best chain
4282016-07-12T22:52:46  <sipa> under certain circumstances we do accept unsolicited blocks
4292016-07-12T22:53:02  *** fengling has joined #bitcoin-core-dev
4302016-07-12T22:55:18  *** arubi has joined #bitcoin-core-dev
4312016-07-12T22:57:46  *** fengling has quit IRC
4322016-07-12T22:59:27  <midnightmagic> sipa: can you give me an example of one of those edge cases? I don't need gritty details..
4332016-07-12T23:00:21  <sipa> midnightmagic: not edge case; it's very intentional... for example, nodes connected to the (old) relay network would get blocks pushed directly to them
4342016-07-12T23:00:27  <sipa> it would be silly to not accept those
4352016-07-12T23:02:07  <midnightmagic> sipa: So an old-style block chatter is still accepted wholesale and validation proceeds (and then stored but still not considered canonical head until Y+1 indicates the fork has overtaken X.)
4362016-07-12T23:02:48  <sipa> midnightmagic: well in almost all cases the new block is not a reorg
4372016-07-12T23:02:55  <sipa> but we don't know that in advance
4382016-07-12T23:03:01  <bsm117532> petertodd: I notice in python-bitcoinlib that CScript treats OP_0 as an empty data push b''.  It's used as the segwit version number.  Is there good reason to treat OP_0 as an empty data push over a small integer with value 0?
4392016-07-12T23:03:02  *** deego has joined #bitcoin-core-dev
4402016-07-12T23:03:31  <sipa> bsm117532: you can't change the semantics of the scripting language...
4412016-07-12T23:03:41  <sipa> OP_0 by definition pushes the byte sequence ''
4422016-07-12T23:03:46  <bsm117532> Is that changing the semantics?
4432016-07-12T23:03:49  <sipa> yes
4442016-07-12T23:04:02  <sipa> if you would compare it to the empty string later, it has to succeed
4452016-07-12T23:04:08  <midnightmagic> sipa: Is the strict difficulty of the block hash now considered in terms of deciding validity of head? I know you guys were thinking of doing that instead of just the difficulty target of the block itself..
4462016-07-12T23:04:21  <sipa> bsm117532: the script language stack only has one data type, byte array
4472016-07-12T23:04:35  <sipa> some operators treat the elements as numbers, but that's not relevant
4482016-07-12T23:05:14  <bsm117532> sipa: okay, I'm comparing to your bip141 which writes scriptPubKey as: 0 <20-byte-key-hash>, but obviously b'' <20-byte-key-hash> is equivalent.
4492016-07-12T23:05:31  <sipa> no
4502016-07-12T23:05:54  <sipa> it's OP_0 and then a 20-byte push
4512016-07-12T23:06:08  <sipa> oh, that's what you mean
4522016-07-12T23:06:21  <sipa> why can't you use OP_0 ?
4532016-07-12T23:06:30  <bsm117532> Yes.  python-bitcoinlib treats it as an empty byte array push, followed by a 20-byte push.
4542016-07-12T23:06:48  <sipa> that's correct
4552016-07-12T23:06:58  <bsm117532> It doesn't give me OP_0.  It decodes OP_1...OP_16 but does not decode OP_0.
4562016-07-12T23:07:26  <bsm117532> This is to do with the __iter__ method of CScript, which parses it.
4572016-07-12T23:07:34  <sipa> that sounds like a bug
4582016-07-12T23:07:41  <bsm117532> That's why I asked.  ;-)
4592016-07-12T23:07:47  <sipa> but i don't know python-bitcoinlib
4602016-07-12T23:08:03  <bsm117532> Maybe petertodd will happen by ;-)
4612016-07-12T23:11:41  <bsm117532> There are two iterators, a "raw" iterator, for people who want to tell the difference between PUSHDATA* and a "cooked" iterator which is supposed to be "intuitive" or something.  I'll put the difference into the "cooked" iterator.
4622016-07-12T23:11:52  *** deego has left #bitcoin-core-dev
4632016-07-12T23:12:08  <bsm117532> so now I get: CScript([OP_0, x('a87e6d173860ff1dfc8849f2638182aa36058389')])
4642016-07-12T23:37:04  *** harrymm has quit IRC
4652016-07-12T23:43:04  *** Cory has quit IRC
4662016-07-12T23:53:04  *** harrymm has joined #bitcoin-core-dev
4672016-07-12T23:54:36  *** fengling has joined #bitcoin-core-dev
4682016-07-12T23:59:26  *** fengling has quit IRC