1 2016-07-12T00:01:03  *** Giszmo has joined #bitcoin-core-dev
  2 2016-07-12T00:04:34  *** TomMc has quit IRC
  3 2016-07-12T00:05:52  *** Giszmo has quit IRC
  4 2016-07-12T00:06:57  *** Giszmo has joined #bitcoin-core-dev
  5 2016-07-12T00:28:09  *** AaronvanW has quit IRC
  6 2016-07-12T00:35:21  *** TomMc has joined #bitcoin-core-dev
  7 2016-07-12T00:53:22  *** Chris_Stewart_5 has quit IRC
  8 2016-07-12T00:56:22  *** Chris_Stewart_5 has joined #bitcoin-core-dev
  9 2016-07-12T01:02:52  *** belcher has quit IRC
 10 2016-07-12T01:08:54  *** Giszmo1 has joined #bitcoin-core-dev
 11 2016-07-12T01:09:06  *** Giszmo has quit IRC
 12 2016-07-12T01:10:24  *** Chris_Stewart_5 has quit IRC
 13 2016-07-12T01:15:46  *** Ylbam has quit IRC
 14 2016-07-12T01:30:43  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 15 2016-07-12T01:31:16  *** Lysander1 has joined #bitcoin-core-dev
 16 2016-07-12T01:34:25  *** Lysanders has quit IRC
 17 2016-07-12T01:39:27  *** xinxi has joined #bitcoin-core-dev
 18 2016-07-12T01:40:04  *** Giszmo1 has quit IRC
 19 2016-07-12T01:40:43  *** luke-jr has quit IRC
 20 2016-07-12T01:41:28  *** Giszmo has joined #bitcoin-core-dev
 21 2016-07-12T01:43:34  *** xinxi has quit IRC
 22 2016-07-12T01:48:39  *** TomMc has quit IRC
 23 2016-07-12T01:51:28  *** Giszmo has quit IRC
 24 2016-07-12T01:51:42  <phantomcircuit> fyi there's someone repeatedly connecting and disconnecting from a narrow ip range
 25 2016-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
 26 2016-07-12T01:52:41  <phantomcircuit> 37.97.164.159
 27 2016-07-12T01:52:43  <phantomcircuit> 37.97.164.160
 28 2016-07-12T01:52:47  <phantomcircuit> 37.97.164.230
 29 2016-07-12T01:52:48  <phantomcircuit> 37.97.164.231
 30 2016-07-12T01:55:45  *** afk11 has quit IRC
 31 2016-07-12T01:56:34  *** afk11 has joined #bitcoin-core-dev
 32 2016-07-12T01:56:34  *** afk11 has quit IRC
 33 2016-07-12T01:56:34  *** afk11 has joined #bitcoin-core-dev
 34 2016-07-12T01:58:30  *** harrymm has quit IRC
 35 2016-07-12T02:12:12  *** harrymm has joined #bitcoin-core-dev
 36 2016-07-12T02:15:36  *** frankenmint has quit IRC
 37 2016-07-12T02:19:28  <Chris_Stewart_5> Can you receive messages on the p2p network from a non standard port? ie not 8333/18333
 38 2016-07-12T02:19:48  <Chris_Stewart_5> if I send a version message with the non standard port?
 39 2016-07-12T02:29:59  <sipa> yes
 40 2016-07-12T02:30:15  <sipa> but nodes strongly prefer connecting to nodes on the standard port
 41 2016-07-12T02:30:38  <sipa> they will pretty much only choose nodes with nonstandard ports if they have no other option
 42 2016-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
 43 2016-07-12T02:34:55  *** frankenmint has joined #bitcoin-core-dev
 44 2016-07-12T02:39:43  *** fengling has quit IRC
 45 2016-07-12T02:40:07  *** fengling has joined #bitcoin-core-dev
 46 2016-07-12T02:44:52  *** whphhg has quit IRC
 47 2016-07-12T02:53:16  *** justanotheruser has quit IRC
 48 2016-07-12T02:55:32  *** justanotheruser has joined #bitcoin-core-dev
 49 2016-07-12T03:01:12  *** Chris_Stewart_5 has quit IRC
 50 2016-07-12T03:26:14  *** xinxi has joined #bitcoin-core-dev
 51 2016-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
 52 2016-07-12T03:31:34  *** xinxi has quit IRC
 53 2016-07-12T04:02:36  *** Alopex has quit IRC
 54 2016-07-12T04:03:41  *** Alopex has joined #bitcoin-core-dev
 55 2016-07-12T04:09:30  *** randy-waterhouse has joined #bitcoin-core-dev
 56 2016-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.
 57 2016-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)
 58 2016-07-12T04:16:25  *** luke-jr has joined #bitcoin-core-dev
 59 2016-07-12T04:16:43  <dgenr8> indeed, a 51% attack is a far greater threat than a blocktime slowdown, you get it
 60 2016-07-12T04:18:42  <gmaxwell> what? your analysis is just obviously broken on its face.
 61 2016-07-12T04:19:11  <gmaxwell> it claims that 80% dishonest mining is unable to slew the time.
 62 2016-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.
 63 2016-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
 64 2016-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.
 65 2016-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.)
 66 2016-07-12T04:26:31  <dgenr8> you read that statement completely wrong
 67 2016-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?
 68 2016-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?
 69 2016-07-12T04:34:59  <dgenr8> XT, unlike core, would warn loudly as that 51% attack slowed the generation rate
 70 2016-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?
 71 2016-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.
 72 2016-07-12T04:38:46  *** fengling has quit IRC
 73 2016-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.
 74 2016-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
 75 2016-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.
 76 2016-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.
 77 2016-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.
 78 2016-07-12T04:47:35  <gmaxwell> dgenr8: you didn't even notice the successful attack on testnet against classic then, I guess.
 79 2016-07-12T04:48:31  <dgenr8> i did see it was pushed it back a few days
 80 2016-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
 81 2016-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'.
 82 2016-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...
 83 2016-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.
 84 2016-07-12T04:51:36  <gmaxwell> (Especially when it's so easy to demonstrate the exploit on a live network)
 85 2016-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
 86 2016-07-12T04:53:38  <gmaxwell> Fair enough.
 87 2016-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.
 88 2016-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
 89 2016-07-12T04:56:42  <gmaxwell> mplement a much riskier version.
 90 2016-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
 91 2016-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.
 92 2016-07-12T04:58:51  *** xinxi has joined #bitcoin-core-dev
 93 2016-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. :)
 94 2016-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
 95 2016-07-12T05:00:50  <gmaxwell> conduct.
 96 2016-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.
 97 2016-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
 98 2016-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.
 99 2016-07-12T05:04:51  <dgenr8> no, i found it while looking at some other core PR
100 2016-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.
101 2016-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)
102 2016-07-12T05:06:18  <dgenr8> if you recall that effect was found independently weeks later by Peter Tschipper
103 2016-07-12T05:06:51  <dgenr8> its all irrelevant now anyway
104 2016-07-12T05:07:00  *** xinxi has quit IRC
105 2016-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.
106 2016-07-12T05:07:41  <gmaxwell> You can't deny that the commit message was scream loud totally clear about _exactly_ what the change did.
107 2016-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.
108 2016-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
109 2016-07-12T05:08:56  *** xinxi has joined #bitcoin-core-dev
110 2016-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/
111 2016-07-12T05:12:17  <gmaxwell> Though indeed, I guess you only use the words "your sneak attack" and not "backdoor" yourself.
112 2016-07-12T05:16:24  *** kadoban has quit IRC
113 2016-07-12T05:16:44  *** kadoban has joined #bitcoin-core-dev
114 2016-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%.)
115 2016-07-12T05:27:48  *** xinxi_ has joined #bitcoin-core-dev
116 2016-07-12T05:27:48  *** xinxi has quit IRC
117 2016-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.
118 2016-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.
119 2016-07-12T05:30:14  <gmaxwell> I wonder how many bitcoins will be lost by people throwing out wallets that look empty but arn't. :(
120 2016-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.
121 2016-07-12T05:31:19  *** fengling has joined #bitcoin-core-dev
122 2016-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.
123 2016-07-12T05:32:16  *** cryptapus_ has joined #bitcoin-core-dev
124 2016-07-12T05:32:16  *** cryptapus_ has joined #bitcoin-core-dev
125 2016-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
126 2016-07-12T05:37:27  <phantomcircuit> indeed wumpus is right, possibly this could move to #bitcoin
127 2016-07-12T05:38:02  <phantomcircuit> wumpus, fyi you might find this interesting https://github.com/bitcoin/bitcoin/issues/8333
128 2016-07-12T05:38:55  <dgenr8> gmaxwell: breadwallet already detects the condition and corrects it by reconnecting
129 2016-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* :)
130 2016-07-12T05:43:07  <phantomcircuit> wumpus, in a world where i can mess with settings and have an average block validate in 30ms
131 2016-07-12T05:43:18  <phantomcircuit> thanks to my 8GiB sigcache and 16GiB dbcache
132 2016-07-12T05:43:33  <phantomcircuit> (and a hack that loads the entire utxo into cache on start)
133 2016-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 )
134 2016-07-12T05:44:59  <wumpus> phantomcircuit: anyhow to say more about it we
135 2016-07-12T05:45:06  <wumpus> 'd need detailed profiling of that step
136 2016-07-12T05:46:35  <phantomcircuit> gmaxwell, im working on that, i have a plan to drill down and around the mantle
137 2016-07-12T05:46:44  <phantomcircuit> i only need a few trillion dollars
138 2016-07-12T05:47:23  *** xinxi_ has quit IRC
139 2016-07-12T05:47:47  <gmaxwell> /msg phantomcircuit has the patent issued yet for the neutrion based transciever yet?
140 2016-07-12T05:49:29  <wumpus> gmaxwell: yes can only get as close as possible to the physical limit
141 2016-07-12T05:50:11  *** xinxi has joined #bitcoin-core-dev
142 2016-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.
143 2016-07-12T05:55:02  *** xinxi has quit IRC
144 2016-07-12T06:02:52  <wumpus> gmaxwell: what kind of things, optimizing the P2P protocol? network infrastructure?
145 2016-07-12T06:04:49  <wumpus> as long as any part of validation is the bottleneck, optimizing that is still part of 'speeding up core'
146 2016-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
147 2016-07-12T06:09:23  <wumpus> (but that's what the relay network is for)
148 2016-07-12T06:21:36  *** Yv7trNY has joined #bitcoin-core-dev
149 2016-07-12T06:24:41  *** Yv7trNY has quit IRC
150 2016-07-12T06:26:27  *** xinxi has joined #bitcoin-core-dev
151 2016-07-12T06:27:33  *** davidlj95 has joined #bitcoin-core-dev
152 2016-07-12T06:37:12  <sipa> phantomcircuit: it's good to see that part of the logic becoming measurable :)
153 2016-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
154 2016-07-12T06:47:32  *** xinxi has quit IRC
155 2016-07-12T06:48:28  *** Ylbam has joined #bitcoin-core-dev
156 2016-07-12T06:53:52  *** cryptapus_ has quit IRC
157 2016-07-12T06:57:45  *** xinxi has joined #bitcoin-core-dev
158 2016-07-12T07:22:28  *** whphhg has joined #bitcoin-core-dev
159 2016-07-12T07:30:28  *** kadoban has quit IRC
160 2016-07-12T07:38:13  *** frankenmint has quit IRC
161 2016-07-12T07:38:42  *** frankenmint has joined #bitcoin-core-dev
162 2016-07-12T07:49:42  *** jtimon has joined #bitcoin-core-dev
163 2016-07-12T07:54:08  *** murch has joined #bitcoin-core-dev
164 2016-07-12T07:58:23  *** DigiByteDev has joined #bitcoin-core-dev
165 2016-07-12T08:15:04  *** tucenaber has quit IRC
166 2016-07-12T08:16:11  *** Alopex has quit IRC
167 2016-07-12T08:17:17  *** Alopex has joined #bitcoin-core-dev
168 2016-07-12T08:24:11  *** Alopex has quit IRC
169 2016-07-12T08:25:30  *** xinxi has quit IRC
170 2016-07-12T08:34:04  *** asoltys has quit IRC
171 2016-07-12T08:37:23  *** xinxi has joined #bitcoin-core-dev
172 2016-07-12T08:38:31  *** xinxi has quit IRC
173 2016-07-12T08:40:34  *** asoltys has joined #bitcoin-core-dev
174 2016-07-12T08:49:48  *** jannes has joined #bitcoin-core-dev
175 2016-07-12T08:53:40  *** tucenaber has joined #bitcoin-core-dev
176 2016-07-12T08:53:59  *** tucenaber has joined #bitcoin-core-dev
177 2016-07-12T08:58:17  *** whphhg_ has joined #bitcoin-core-dev
178 2016-07-12T09:01:07  *** whphhg has quit IRC
179 2016-07-12T09:06:42  *** DigiByteDev has quit IRC
180 2016-07-12T09:07:26  *** fengling has quit IRC
181 2016-07-12T09:12:07  *** mkarrer has joined #bitcoin-core-dev
182 2016-07-12T09:12:48  *** mkarrer has joined #bitcoin-core-dev
183 2016-07-12T09:20:16  *** ebfull has joined #bitcoin-core-dev
184 2016-07-12T09:23:26  *** whphhg_ is now known as whphhg
185 2016-07-12T09:25:57  *** randy-waterhouse has quit IRC
186 2016-07-12T09:45:37  *** frankenmint has quit IRC
187 2016-07-12T09:47:22  <GitHub97> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/4831a16223dbb42da3091e616c47eeb01f53f73b
188 2016-07-12T09:47:22  <GitHub97> bitcoin/master 4831a16 Wladimir J. van der Laan: qt: periodic translation update...
189 2016-07-12T09:49:18  *** moli has quit IRC
190 2016-07-12T09:55:05  *** jtimon has quit IRC
191 2016-07-12T09:57:28  *** laurentmt has joined #bitcoin-core-dev
192 2016-07-12T09:57:33  *** mkarrer has quit IRC
193 2016-07-12T10:00:34  *** moli has joined #bitcoin-core-dev
194 2016-07-12T10:02:49  *** mkarrer has joined #bitcoin-core-dev
195 2016-07-12T10:03:24  *** go1111111 has quit IRC
196 2016-07-12T10:09:34  *** mkarrer has quit IRC
197 2016-07-12T10:12:15  *** mkarrer has joined #bitcoin-core-dev
198 2016-07-12T10:17:07  *** davidlj95 has left #bitcoin-core-dev
199 2016-07-12T10:27:29  *** xinxi has joined #bitcoin-core-dev
200 2016-07-12T10:33:39  *** AaronvanW has joined #bitcoin-core-dev
201 2016-07-12T10:33:39  *** AaronvanW has joined #bitcoin-core-dev
202 2016-07-12T10:34:33  *** fengling has joined #bitcoin-core-dev
203 2016-07-12T10:39:26  *** fengling has quit IRC
204 2016-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
205 2016-07-12T10:55:03  *** Giszmo has joined #bitcoin-core-dev
206 2016-07-12T11:05:26  *** arubi has quit IRC
207 2016-07-12T11:06:06  *** arubi has joined #bitcoin-core-dev
208 2016-07-12T11:07:58  *** Giszmo has quit IRC
209 2016-07-12T11:11:34  *** Giszmo has joined #bitcoin-core-dev
210 2016-07-12T11:20:31  *** Giszmo has quit IRC
211 2016-07-12T11:31:28  *** jtimon has joined #bitcoin-core-dev
212 2016-07-12T11:35:11  *** moli has quit IRC
213 2016-07-12T11:36:14  *** fengling has joined #bitcoin-core-dev
214 2016-07-12T11:41:06  *** fengling has quit IRC
215 2016-07-12T11:54:47  *** Chris_Stewart_5 has joined #bitcoin-core-dev
216 2016-07-12T11:57:02  *** arubi has quit IRC
217 2016-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
218 2016-07-12T11:57:39  *** arubi has joined #bitcoin-core-dev
219 2016-07-12T11:59:47  *** laurentmt has quit IRC
220 2016-07-12T12:06:52  *** YOU-JI has joined #bitcoin-core-dev
221 2016-07-12T12:17:52  *** Chris_Stewart_5 has quit IRC
222 2016-07-12T12:27:52  *** jannes has quit IRC
223 2016-07-12T12:36:37  *** arubi has quit IRC
224 2016-07-12T12:37:46  *** fengling has joined #bitcoin-core-dev
225 2016-07-12T12:39:33  *** jannes has joined #bitcoin-core-dev
226 2016-07-12T12:42:26  *** fengling has quit IRC
227 2016-07-12T12:50:05  *** arubi has joined #bitcoin-core-dev
228 2016-07-12T12:58:38  *** G1lius has joined #bitcoin-core-dev
229 2016-07-12T13:15:26  *** arubi has quit IRC
230 2016-07-12T13:16:16  *** arubi has joined #bitcoin-core-dev
231 2016-07-12T13:22:58  *** JackH has quit IRC
232 2016-07-12T13:34:11  *** TomMc has joined #bitcoin-core-dev
233 2016-07-12T13:35:39  *** YOU-JI has quit IRC
234 2016-07-12T13:39:07  *** GreenIsMyPepper has quit IRC
235 2016-07-12T13:39:16  *** fengling has joined #bitcoin-core-dev
236 2016-07-12T13:41:07  *** GreenIsMyPepper has joined #bitcoin-core-dev
237 2016-07-12T13:44:06  *** fengling has quit IRC
238 2016-07-12T13:53:00  *** Guyver2 has joined #bitcoin-core-dev
239 2016-07-12T13:53:42  *** zooko has joined #bitcoin-core-dev
240 2016-07-12T13:55:25  *** lysobit- has joined #bitcoin-core-dev
241 2016-07-12T13:56:27  *** GreenIsMyPepper has quit IRC
242 2016-07-12T13:56:55  *** musalbas- has joined #bitcoin-core-dev
243 2016-07-12T14:01:03  *** kadoban has joined #bitcoin-core-dev
244 2016-07-12T14:01:18  *** baldur has quit IRC
245 2016-07-12T14:10:11  *** GreenIsMyPepper has joined #bitcoin-core-dev
246 2016-07-12T14:12:33  *** dgenr8 has quit IRC
247 2016-07-12T14:13:30  *** dgenr8 has joined #bitcoin-core-dev
248 2016-07-12T14:15:43  *** BCBot has quit IRC
249 2016-07-12T14:18:39  *** fifth_ has joined #bitcoin-core-dev
250 2016-07-12T14:18:55  *** Chris_Stewart_5 has joined #bitcoin-core-dev
251 2016-07-12T14:26:39  *** moli has joined #bitcoin-core-dev
252 2016-07-12T14:27:01  <michagogo> Has anyone looked into packaging Bitcoin Core into a snap?
253 2016-07-12T14:27:11  <michagogo> (Ubuntu's new packaging format)
254 2016-07-12T14:27:16  *** murch has quit IRC
255 2016-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
256 2016-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
257 2016-07-12T14:29:38  <michagogo> (i.e. it _might_ let us sanely get Bitcoin Core into Ubuntu)
258 2016-07-12T14:29:54  <sipa> sounds interesting
259 2016-07-12T14:31:15  *** moli has quit IRC
260 2016-07-12T14:32:51  *** moli has joined #bitcoin-core-dev
261 2016-07-12T14:39:30  <jonasschnelli> sounds good... the current PPA is maintained by thebluematt, maybe he's interested
262 2016-07-12T14:40:48  *** fengling has joined #bitcoin-core-dev
263 2016-07-12T14:45:46  *** fengling has quit IRC
264 2016-07-12T15:01:45  *** Chris_Stewart_5 has quit IRC
265 2016-07-12T15:05:12  *** Chris_Stewart_5 has joined #bitcoin-core-dev
266 2016-07-12T15:15:45  *** GreenIsMyPepper has quit IRC
267 2016-07-12T15:17:45  *** GreenIsMyPepper has joined #bitcoin-core-dev
268 2016-07-12T15:22:15  *** GreenIsMyPepper has quit IRC
269 2016-07-12T15:23:03  *** fifth_ has quit IRC
270 2016-07-12T15:25:16  *** GreenIsMyPepper has joined #bitcoin-core-dev
271 2016-07-12T15:47:14  *** laurentmt has joined #bitcoin-core-dev
272 2016-07-12T16:33:42  *** Chris_Stewart_5 has quit IRC
273 2016-07-12T16:35:28  *** Chris_Stewart_5 has joined #bitcoin-core-dev
274 2016-07-12T16:44:28  *** fengling has joined #bitcoin-core-dev
275 2016-07-12T16:49:06  *** fengling has quit IRC
276 2016-07-12T16:56:20  *** G1lius has quit IRC
277 2016-07-12T16:59:18  *** spudowiar has joined #bitcoin-core-dev
278 2016-07-12T17:33:56  *** jannes has quit IRC
279 2016-07-12T17:45:25  *** fengling has joined #bitcoin-core-dev
280 2016-07-12T17:48:43  *** Chris_Stewart_5 has quit IRC
281 2016-07-12T17:50:06  *** fengling has quit IRC
282 2016-07-12T17:54:28  *** paveljanik has joined #bitcoin-core-dev
283 2016-07-12T18:03:38  <xinxi> I've herd there is slack group for Bitcoin core dev. Who can tell me the URL?
284 2016-07-12T18:07:16  <btcdrak> xinxi: slack.bitcoincore.org
285 2016-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.
286 2016-07-12T18:07:34  <btcdrak> but it's more a community slack.
287 2016-07-12T18:07:53  <xinxi> thank you.
288 2016-07-12T18:15:16  *** Chris_Stewart_5 has joined #bitcoin-core-dev
289 2016-07-12T18:16:29  <xinxi> Oh, messages sent on slack cannot be seen here.
290 2016-07-12T18:16:41  *** spudowiar has quit IRC
291 2016-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
292 2016-07-12T18:20:14  <Chris_Stewart_5> I keep getting a NotFound message response, when I know the tx exists
293 2016-07-12T18:20:34  <sipa> Chris_Stewart_5: you can't just request any transaction
294 2016-07-12T18:20:47  <sipa> only things that have been advertized to you
295 2016-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)
296 2016-07-12T18:22:52  *** adamg has quit IRC
297 2016-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?
298 2016-07-12T18:24:13  <sipa> Chris_Stewart_5: the network tries to hide where a transaction originates
299 2016-07-12T18:24:36  <sipa> for that, transactions are relayed with random delays between them, and in different order for different peers
300 2016-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
301 2016-07-12T18:25:40  <sipa> Chris_Stewart_5: -reindex just throws away the database and builds a new one
302 2016-07-12T18:25:50  <Chris_Stewart_5> Sorry i meant -txindex
303 2016-07-12T18:25:57  <sipa> yes, that's for local consumption
304 2016-07-12T18:26:01  <sipa> not exposed to the network
305 2016-07-12T18:26:20  *** adamg has joined #bitcoin-core-dev
306 2016-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
307 2016-07-12T18:27:22  <Chris_Stewart_5> What file is the code in wrt to transaction propogation? main.cpp? net.cpp?
308 2016-07-12T18:27:27  <sipa> both
309 2016-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
310 2016-07-12T18:32:46  <sipa> no
311 2016-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
312 2016-07-12T18:33:04  <sipa> it could be clarified
313 2016-07-12T18:33:23  <sipa> but it's not wrong that a tx is sent as response to getdata TX
314 2016-07-12T18:34:11  <sipa> but i agree it's a bit misleading
315 2016-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?
316 2016-07-12T18:37:08  <sipa> or through the bip35 mempool command
317 2016-07-12T18:38:41  <Chris_Stewart_5> gotcha, thanks.
318 2016-07-12T18:40:13  <sipa> also, after relay, you only have a finite amount of time to getdata
319 2016-07-12T18:40:20  <sipa> i think 15 minutes by default
320 2016-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?
321 2016-07-12T18:42:29  <sipa> tx propagation has nothing to do with blocks
322 2016-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
323 2016-07-12T18:46:56  *** fengling has joined #bitcoin-core-dev
324 2016-07-12T18:49:07  *** gitju has joined #bitcoin-core-dev
325 2016-07-12T18:50:11  *** gitju has left #bitcoin-core-dev
326 2016-07-12T18:51:46  *** fengling has quit IRC
327 2016-07-12T19:01:03  *** Chris_Stewart_5 has quit IRC
328 2016-07-12T19:09:45  *** Chris_Stewart_5 has joined #bitcoin-core-dev
329 2016-07-12T19:14:11  *** Chris_Stewart_5 has quit IRC
330 2016-07-12T19:17:21  *** Chris_Stewart_5 has joined #bitcoin-core-dev
331 2016-07-12T19:25:03  *** ryan`c has joined #bitcoin-core-dev
332 2016-07-12T19:29:31  *** owowo has quit IRC
333 2016-07-12T19:30:59  *** ryan`c has quit IRC
334 2016-07-12T19:35:49  *** ryan`c has joined #bitcoin-core-dev
335 2016-07-12T19:37:40  *** Chris_Stewart_5 has quit IRC
336 2016-07-12T19:45:26  *** ryan-c has quit IRC
337 2016-07-12T19:46:21  *** ryan`c is now known as ryan-c
338 2016-07-12T19:48:29  *** fengling has joined #bitcoin-core-dev
339 2016-07-12T19:53:26  *** fengling has quit IRC
340 2016-07-12T19:54:09  *** owowo has joined #bitcoin-core-dev
341 2016-07-12T19:55:30  *** Chris_Stewart_5 has joined #bitcoin-core-dev
342 2016-07-12T19:55:33  *** go1111111 has joined #bitcoin-core-dev
343 2016-07-12T19:56:18  *** frankenmint has joined #bitcoin-core-dev
344 2016-07-12T19:56:20  *** JackH has joined #bitcoin-core-dev
345 2016-07-12T20:02:52  <bsm117532> My transactions spending segwit outputs are being rejected by sendrawtransaction...
346 2016-07-12T20:03:10  <sipa> what code?
347 2016-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?
348 2016-07-12T20:03:31  <sipa> indeed
349 2016-07-12T20:03:53  <bsm117532> 64: non-mandatory-script-verify-flag (Script evaluated without error but finished with a false/empty top stack element)
350 2016-07-12T20:04:19  <bsm117532> The transaction is https://www.zerobin.net/?d2c7842e69b63293#PUa9xa3YL9B3N2dwSlbcmfLVMSxyeaUvWJ4YLtp9cEQ=
351 2016-07-12T20:04:26  <sipa> that likely means your signature is incorrect
352 2016-07-12T20:04:31  <bsm117532> Hmmm ok
353 2016-07-12T20:09:52  *** frankenmint has quit IRC
354 2016-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?
355 2016-07-12T20:17:09  *** Chris_Stewart_5 has quit IRC
356 2016-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=
357 2016-07-12T20:20:06  <bsm117532> Can someone explain the difference in what sendrawtransaction is putting as the second element of the witness data?
358 2016-07-12T20:20:30  <sipa> yup, that looks like an uncompressed pubkey
359 2016-07-12T20:21:07  <bsm117532> Are uncompressed pubkeys required?  AFAICT that's the only difference between the two.
360 2016-07-12T20:21:15  <sipa> no
361 2016-07-12T20:21:32  <sipa> they're even discouraged and no modern bitcoin core wallet will use them by default
362 2016-07-12T20:21:57  <sipa> but if you have a very old wallet file or have imported uncompressed keys, there is no choice
363 2016-07-12T20:22:07  <sipa> *won't use them by default
364 2016-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.
365 2016-07-12T20:23:21  <sipa> i can guarantee you that compressed pubkeys work
366 2016-07-12T20:23:35  <sipa> i suspect that you're just signing the incorrect signature hash
367 2016-07-12T20:24:04  <bsm117532> That's entirely possible.
368 2016-07-12T20:24:23  <sipa> (that's just from experience of other people seeing fail there)
369 2016-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.
370 2016-07-12T20:25:36  <sipa> did you import keys, ever?
371 2016-07-12T20:27:01  *** belcher has joined #bitcoin-core-dev
372 2016-07-12T20:28:38  <bsm117532> Hmmm...possibly.
373 2016-07-12T20:28:51  <bsm117532> Should I recreate my wallet then?
374 2016-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)
375 2016-07-12T20:29:20  <sipa> i wouldn't bother
376 2016-07-12T20:29:45  <bsm117532> Hmm maybe I just got unlucky with the chosen input.
377 2016-07-12T20:29:51  *** zooko has quit IRC
378 2016-07-12T20:32:13  * bsm117532 beats on BIP 143.  I knew it was unlikely that my sighash was correct...
379 2016-07-12T20:42:42  * bsm117532 sees now...BIP 143 isn't even remotely close to the pre-segwit algorithm.
380 2016-07-12T20:43:14  <sipa> nope
381 2016-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
382 2016-07-12T20:43:59  <bsm117532> In my defense, I wrote in the python-bitcoinlib PR that I didn't implement this yet!  ;-)
383 2016-07-12T20:50:03  *** fengling has joined #bitcoin-core-dev
384 2016-07-12T20:54:46  *** fengling has quit IRC
385 2016-07-12T21:01:10  <bsm117532> In BIP 143, this line:   if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) {
386 2016-07-12T21:01:25  <bsm117532> Isn't it simpler to just say: if(nHashType | SIGHASH_ALL)  ?
387 2016-07-12T21:02:28  <bsm117532> errr.... if(nHashType & SIGHASH_ALL)
388 2016-07-12T21:04:23  <sipa> that would not be the same, i think?
389 2016-07-12T21:05:00  <bsm117532> I think it's the same unless there are more than 4 SIGHASH_* types
390 2016-07-12T21:07:53  <sipa> there are 6 combinations
391 2016-07-12T21:08:08  <sipa> but the sighash byte can have 256 values
392 2016-07-12T21:08:38  <sipa> all of which map to one of those 6 formulas
393 2016-07-12T21:10:27  *** Guyver2 has quit IRC
394 2016-07-12T21:11:41  <bsm117532> I see.  I thought it was just a bitmap.
395 2016-07-12T21:12:11  <bsm117532> Reference implementation is easy to translate to python, I'll stop trying to "improve" it.  ;-)
396 2016-07-12T21:14:03  <sipa> https://github.com/bitcoin/bitcoin/blob/master/qa/rpc-tests/test_framework/script.py#L908
397 2016-07-12T21:15:34  <bsm117532> Thanks!
398 2016-07-12T21:17:37  *** Avinty-L_ has joined #bitcoin-core-dev
399 2016-07-12T21:18:58  <bsm117532> Sorry I hadn't realized this was so close to petertodd's repo.
400 2016-07-12T21:19:02  * bsm117532 diffs.
401 2016-07-12T21:19:50  <sipa> i think it forked off a long time ago
402 2016-07-12T21:20:06  <sipa> it's a forked, stripped, and then extended version just for tests
403 2016-07-12T21:20:46  <bsm117532> makes sense.
404 2016-07-12T21:24:17  *** bustd_soket has quit IRC
405 2016-07-12T21:25:31  *** spudowiar has joined #bitcoin-core-dev
406 2016-07-12T21:25:39  <sipa> but feel free to steal/donate code of course
407 2016-07-12T21:25:59  <bsm117532> Thanks, I'll attribute what I steal.
408 2016-07-12T21:26:02  *** jtimon has quit IRC
409 2016-07-12T21:32:55  *** laurentmt has quit IRC
410 2016-07-12T21:35:26  *** Avinty-L_ has quit IRC
411 2016-07-12T21:36:54  *** bustd_soket has joined #bitcoin-core-dev
412 2016-07-12T21:37:47  *** Avinty_L_ has joined #bitcoin-core-dev
413 2016-07-12T21:43:12  *** TomMc has quit IRC
414 2016-07-12T21:45:38  *** Avinty_L_ has joined #bitcoin-core-dev
415 2016-07-12T21:47:16  *** Avinty_L_ has quit IRC
416 2016-07-12T21:51:33  *** fengling has joined #bitcoin-core-dev
417 2016-07-12T21:56:25  *** TomMc has joined #bitcoin-core-dev
418 2016-07-12T21:56:26  *** fengling has quit IRC
419 2016-07-12T22:09:19  *** Avinty_L has joined #bitcoin-core-dev
420 2016-07-12T22:13:55  *** Avinty_L has quit IRC
421 2016-07-12T22:17:41  *** Chris_Stewart_5 has joined #bitcoin-core-dev
422 2016-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?
423 2016-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?
424 2016-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.
425 2016-07-12T22:41:40  *** arubi has quit IRC
426 2016-07-12T22:51:49  <sipa> midnightmagic: we keep track of the headers
427 2016-07-12T22:52:06  <sipa> midnightmagic: but only actively try to fetch the blocks if they're overtaking our best chain
428 2016-07-12T22:52:46  <sipa> under certain circumstances we do accept unsolicited blocks
429 2016-07-12T22:53:02  *** fengling has joined #bitcoin-core-dev
430 2016-07-12T22:55:18  *** arubi has joined #bitcoin-core-dev
431 2016-07-12T22:57:46  *** fengling has quit IRC
432 2016-07-12T22:59:27  <midnightmagic> sipa: can you give me an example of one of those edge cases? I don't need gritty details..
433 2016-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
434 2016-07-12T23:00:27  <sipa> it would be silly to not accept those
435 2016-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.)
436 2016-07-12T23:02:48  <sipa> midnightmagic: well in almost all cases the new block is not a reorg
437 2016-07-12T23:02:55  <sipa> but we don't know that in advance
438 2016-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?
439 2016-07-12T23:03:02  *** deego has joined #bitcoin-core-dev
440 2016-07-12T23:03:31  <sipa> bsm117532: you can't change the semantics of the scripting language...
441 2016-07-12T23:03:41  <sipa> OP_0 by definition pushes the byte sequence ''
442 2016-07-12T23:03:46  <bsm117532> Is that changing the semantics?
443 2016-07-12T23:03:49  <sipa> yes
444 2016-07-12T23:04:02  <sipa> if you would compare it to the empty string later, it has to succeed
445 2016-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..
446 2016-07-12T23:04:21  <sipa> bsm117532: the script language stack only has one data type, byte array
447 2016-07-12T23:04:35  <sipa> some operators treat the elements as numbers, but that's not relevant
448 2016-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.
449 2016-07-12T23:05:31  <sipa> no
450 2016-07-12T23:05:54  <sipa> it's OP_0 and then a 20-byte push
451 2016-07-12T23:06:08  <sipa> oh, that's what you mean
452 2016-07-12T23:06:21  <sipa> why can't you use OP_0 ?
453 2016-07-12T23:06:30  <bsm117532> Yes.  python-bitcoinlib treats it as an empty byte array push, followed by a 20-byte push.
454 2016-07-12T23:06:48  <sipa> that's correct
455 2016-07-12T23:06:58  <bsm117532> It doesn't give me OP_0.  It decodes OP_1...OP_16 but does not decode OP_0.
456 2016-07-12T23:07:26  <bsm117532> This is to do with the __iter__ method of CScript, which parses it.
457 2016-07-12T23:07:34  <sipa> that sounds like a bug
458 2016-07-12T23:07:41  <bsm117532> That's why I asked.  ;-)
459 2016-07-12T23:07:47  <sipa> but i don't know python-bitcoinlib
460 2016-07-12T23:08:03  <bsm117532> Maybe petertodd will happen by ;-)
461 2016-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.
462 2016-07-12T23:11:52  *** deego has left #bitcoin-core-dev
463 2016-07-12T23:12:08  <bsm117532> so now I get: CScript([OP_0, x('a87e6d173860ff1dfc8849f2638182aa36058389')])
464 2016-07-12T23:37:04  *** harrymm has quit IRC
465 2016-07-12T23:43:04  *** Cory has quit IRC
466 2016-07-12T23:53:04  *** harrymm has joined #bitcoin-core-dev
467 2016-07-12T23:54:36  *** fengling has joined #bitcoin-core-dev
468 2016-07-12T23:59:26  *** fengling has quit IRC