1 2016-07-20T00:02:29  *** Giszmo has joined #bitcoin-core-dev
  2 2016-07-20T00:08:28  *** PRab has joined #bitcoin-core-dev
  3 2016-07-20T00:16:13  *** PRab has quit IRC
  4 2016-07-20T00:17:30  *** NicLin has joined #bitcoin-core-dev
  5 2016-07-20T00:25:48  *** Ylbam has quit IRC
  6 2016-07-20T00:32:43  <gmaxwell> luke-jr: so whats the deal with this sigops checking thing. Help me understand your position.
  7 2016-07-20T00:33:21  <luke-jr> gmaxwell: does the comment I just posted help? or is there still confusion on it?
  8 2016-07-20T00:33:29  <luke-jr> (literally seconds ago)
  9 2016-07-20T00:34:00  * gmaxwell goes to read
 10 2016-07-20T00:35:46  *** fengling has quit IRC
 11 2016-07-20T00:38:39  <GitHub99> [bitcoin] pstratem opened pull request #8376: Fix exception message to reference actual thrower. (master...2016-07-19-cwallet-sethmasterkey) https://github.com/bitcoin/bitcoin/pull/8376
 12 2016-07-20T00:39:55  <gmaxwell> okay, I see. We probably should make bare multisig non-standard, but it would be inadvisable to do that without a lot of notice and time.
 13 2016-07-20T00:40:04  <gmaxwell> It shouldn't be done accidentally on the sly via another fix.
 14 2016-07-20T00:40:42  <luke-jr> sure, I consider bare multisig policy entirely unrelated to these 2 PRs
 15 2016-07-20T00:40:57  <CodeShark> what's bare multisig?
 16 2016-07-20T00:41:04  <luke-jr> I think both PRs should be merged (once sipa's is updated to not remove the current bytespersigop)
 17 2016-07-20T00:41:10  <luke-jr> CodeShark: multisig without p2sh
 18 2016-07-20T00:41:30  <sipa> luke-jr: my PR does not remove -bytespersigop
 19 2016-07-20T00:41:40  <luke-jr> CodeShark: accidentally broken in 0.12, fixed in #8364
 20 2016-07-20T00:41:55  <luke-jr> sipa: it removes the current bytespersigop and adds a new one that does soemthing different.
 21 2016-07-20T00:42:00  <gmaxwell> luke-jr: okay, so if we're ordering transactions by the resources they actually use, and we'll make bare multisig non-standard via another path-- then why do we need bytespersigop?
 22 2016-07-20T00:42:51  <luke-jr> gmaxwell: for its original purpose: to filter spam misusing multisig
 23 2016-07-20T00:43:18  <gmaxwell> well what kind of spam? people trying to store lots of data don't have a problem having more bytes.
 24 2016-07-20T00:44:13  <gmaxwell> If someone is trying to burn signature operations, we're protected by the sigops limit and protected by the fact that sigops limit burning transactions have to pay as much fees as a set of ordinary txn that burns as many sigops.
 25 2016-07-20T00:45:26  <luke-jr> the "make tx take long to check" kind that has an old CVE I can't lookup because the wiki is apparently down(!) :/
 26 2016-07-20T00:45:51  <luke-jr> nm, finally loaded: CVE-2013-2292
 27 2016-07-20T00:46:57  <luke-jr> and apparently there's some kind of spam that dex guy wants to abuse it for as well
 28 2016-07-20T00:47:13  *** fengling has joined #bitcoin-core-dev
 29 2016-07-20T00:47:31  <gmaxwell> yes, but the dex guy won't get hit by the current limit, he may be too ignorant to realize this.
 30 2016-07-20T00:47:37  <luke-jr> simply saying "pay a higher fee" sends the message that the spam is encouraged; at least by padding people can't claim that
 31 2016-07-20T00:48:12  <gmaxwell> luke-jr: so the n minutes to verify thing is stopped by the maximum standard transaction size being 100k. It's a sighash gringing bug. You actually don't want small transactions to trigger that.
 32 2016-07-20T00:48:39  <gmaxwell> luke-jr: in particular they pay as much (or likely more) fee than doing the attack with more ordinary looking transactions.
 33 2016-07-20T00:48:54  *** netsin has quit IRC
 34 2016-07-20T00:48:55  <gmaxwell> So the abusive use really isn't help, abusers will adapt to do whatever works best for them.
 35 2016-07-20T00:49:15  *** alpalp has joined #bitcoin-core-dev
 36 2016-07-20T00:49:16  *** alpalp has joined #bitcoin-core-dev
 37 2016-07-20T00:49:29  <luke-jr> gmaxwell: how do we avoid people looking at this change and saying "see? as long as I pay the higher fee, I have a right to spam" ?
 38 2016-07-20T00:49:31  <gmaxwell> and we are currently left with bare multisig users that, we know know, have problems reliably producing transactions under this policy.
 39 2016-07-20T00:49:33  *** netsin has joined #bitcoin-core-dev
 40 2016-07-20T00:49:56  <luke-jr> gmaxwell: #8364 entirely fixes the current problem
 41 2016-07-20T00:50:10  <gmaxwell> luke-jr: by stating it outright that it's not intended to enable transactions that store unrelated data in the blockchain or intentionally waste resources.
 42 2016-07-20T00:50:16  <gmaxwell> E.g. we could release note that.
 43 2016-07-20T00:50:19  <luke-jr> like we did with OP_RETURN?
 44 2016-07-20T00:50:23  <luke-jr> we all know how that turned out..
 45 2016-07-20T00:50:46  <gmaxwell> luke-jr: but it adds a lot of code that is non-obvious in its exeuction and application.. and which transacting parties should have to model themselves to know if they pass the test or don't.
 46 2016-07-20T00:51:23  <luke-jr> huh? #8364 would fix the bug so transacting parties are never affected
 47 2016-07-20T00:51:51  <luke-jr> (sipa's change would probably do that, though)
 48 2016-07-20T00:52:07  *** justanotheruser has quit IRC
 49 2016-07-20T00:52:15  *** justanot1eruser has joined #bitcoin-core-dev
 50 2016-07-20T00:52:34  <gmaxwell> Yea, I think sipa's change is necessary and sufficient. and 8364 might be okay, but it's more complexity with potential surprise consequences, which at best I wouldn't want to rush out with.
 51 2016-07-20T00:53:08  <gmaxwell> and I think it's not actually needed, except in terms of making it clear that we don't support people storing arbritary non-transaction data in the blockchain.
 52 2016-07-20T00:53:19  <luke-jr> what potential surprise consequences? it's a simple bugfix to existing released code, that only allows more transactions that were false-positives
 53 2016-07-20T00:53:52  <luke-jr> re needed or not: keep in mind miners set their own policies, and the defaults of (eg) disabling bare multisig can be overridden
 54 2016-07-20T00:54:03  *** netsin has quit IRC
 55 2016-07-20T00:54:15  <luke-jr> miners might want to continue mining bare multisig after defaults change, yet not open this attack risk
 56 2016-07-20T00:54:29  <sipa> we're really talking about different problems
 57 2016-07-20T00:54:53  *** justanot1eruser is now known as justanotheruser
 58 2016-07-20T00:54:56  <sipa> you're concerned about sending an unintentional signal that high-sigop transactions are ok
 59 2016-07-20T00:54:57  <luke-jr> if de facto we end up in a situation where nobody is mining multisig, I guess that'd be a good time to remove the current bytespersigop.. but that's 0.14 at the earliest unless miners change it manually AIUI
 60 2016-07-20T00:55:06  <sipa> i'm concerned about blocks being filled with garbage
 61 2016-07-20T00:55:30  <gmaxwell> s/are okay/are okay if you pay some market fee/
 62 2016-07-20T00:55:53  <sipa> i think people will use whatever means necessary to store data in the chain, and saying that this must be stopped for the system to succeed is being blind for reality
 63 2016-07-20T00:56:15  *** netsin has joined #bitcoin-core-dev
 64 2016-07-20T00:56:29  <sipa> however, we do now actually have a fee market
 65 2016-07-20T00:56:31  <gmaxwell> I can write some release note text that says that the network capacity is a shared resource and that just because a usecase is technically possible it doesn't mean that it's an intentionally supported usecase.
 66 2016-07-20T00:56:33  <luke-jr> sipa: if reality is they will, then reality is highly against Bitcoin surviving
 67 2016-07-20T00:56:34  <CodeShark> sipa: I agree - we should not be deciding use cases, only working to ensure incentives don't get out of whack
 68 2016-07-20T00:57:13  <sipa> luke-jr: and policy (and even consensus rules) can be proposed to combat certain behaviour that damages shared resources
 69 2016-07-20T00:57:18  <luke-jr> miners are less likely to mine spam-padded-to-bypass-spam-limits than spam-just-paying-a-higher-fee IMO
 70 2016-07-20T00:57:25  <luke-jr> intentionally*
 71 2016-07-20T00:57:57  <gmaxwell> luke-jr: yea, slightly,-- which is the argument against ltc like 'dust' limits. But it's a minor detail at this point.
 72 2016-07-20T00:58:28  <sipa> but 8364 on itself would allow high-consensus-sigop low-accurate-sigops transactions into blocks, allowing anyone on the network to fill a block with garbage for 1/20th of the market price
 73 2016-07-20T00:58:43  <gmaxwell> They're more likely to do harmful self-profiting things rather than long term community benefiting things if the defaults are so out of wack that they get encouraged by people to change them.
 74 2016-07-20T00:58:46  <sipa> that is a directly exploitable bug we'd be shipping in our mining code
 75 2016-07-20T00:59:06  <sipa> and much more serious than a worry about a potentially misinterpreted signal _to people who are already using it anyway_
 76 2016-07-20T00:59:24  <luke-jr> what justification is there to exclude/replace the current bytespersigop this close to release? it does no harm at worst (especially if sipa's policy change is also included)
 77 2016-07-20T00:59:35  <gmaxwell> not just exploitable, previously actively exploited.
 78 2016-07-20T00:59:49  <luke-jr> sipa: I'm arguing for *both*, not 8364 *instead of* yours
 79 2016-07-20T00:59:55  <sipa> luke-jr: ok, fair enough
 80 2016-07-20T01:00:03  <gmaxwell> luke-jr: the _current_ unmodified bytes per sigops blocks some bare multisig usage.
 81 2016-07-20T01:00:15  <luke-jr> gmaxwell: accidentally
 82 2016-07-20T01:00:22  <gmaxwell> Sure. It's a bug, we need to fix it.
 83 2016-07-20T01:00:34  <luke-jr> so we fix that, and independently add sipa's policy.
 84 2016-07-20T01:00:50  <sipa> luke-jr: both together are acceptable, but more complexity, and i'm not sure what it gains
 85 2016-07-20T01:00:58  <gmaxwell> So to fix that we have to do something there. One option is to take it out. The other option is to do 8364.  I think take it out is superior because with 8365 the marginal benefit from 8364 is small relative to the code complexity-- esp-- as you note, this close to release.
 86 2016-07-20T01:01:04  * luke-jr notes 8364 has been suggested as a fix without any controversy for months now.
 87 2016-07-20T01:01:44  <sipa> but you agree that 8364 (on its own) would be a bad idea?
 88 2016-07-20T01:02:24  <luke-jr> sipa: I don't believe I have sufficient information to answer that.
 89 2016-07-20T01:02:51  <luke-jr> or rather, I have to do some analysis of the information I have, that i have not yet done
 90 2016-07-20T01:04:34  <sipa> as far as i'm concerned, the only thing to prevent is having the mining code get confused by transactions, and producing a block that nobody would want to create
 91 2016-07-20T01:04:37  <gmaxwell> luke-jr: without 8365, 8364 would reintroduct the consensus-sigops block exhaustion attack that was being actively exploited.
 92 2016-07-20T01:05:00  <sipa> wrt concern about resource usage, we should propose to make bare multisig nonstandard
 93 2016-07-20T01:07:17  <gmaxwell> we should. But I think thats is seperate, perhaps just as a note in the release notes.
 94 2016-07-20T01:07:27  <luke-jr> seems like more of an economic concern than technical? after all, people could just pay 20x higher fees. admittedly, not a good situation of course
 95 2016-07-20T01:08:01  <luke-jr> seems just doing 1-of-2 baremultisigs legitimately might actually be an economic concern in the same sense
 96 2016-07-20T01:08:24  *** jcliff42 has quit IRC
 97 2016-07-20T01:08:32  * luke-jr wonders why he has to defend "not 8365's new policy" when he has never argued for omitting it :p
 98 2016-07-20T01:10:04  <gmaxwell> hah.
 99 2016-07-20T01:10:35  <gmaxwell> My comment was just a reply to "notes 8364 has been suggested as a fix without any controversy for months now"  -- apparently I must have missed that fix discussion since I would have complained that it reopened the attack. :)
100 2016-07-20T01:11:08  <luke-jr> mostly on https://github.com/bitcoin/bitcoin/issues/8079
101 2016-07-20T01:11:26  <luke-jr> IIRC
102 2016-07-20T01:11:40  <luke-jr> maybe it got lost in the other bs on that thread
103 2016-07-20T01:11:54  <sipa> i thought 8365 was the obvious fix all the time :)
104 2016-07-20T01:12:07  <luke-jr> bbiab
105 2016-07-20T01:12:58  <sipa> (because i assumed #7081 was intended to fix the sigop exhaustion attack, and its effect on relay was just a side effect instead of an intentional policy)
106 2016-07-20T01:13:46  <gmaxwell> I missed 8079's discussion (because it got kind of hostile at some point).
107 2016-07-20T01:16:17  *** aalex has quit IRC
108 2016-07-20T01:20:22  *** aalex has joined #bitcoin-core-dev
109 2016-07-20T01:24:23  *** hsmiths has quit IRC
110 2016-07-20T01:27:41  *** hsmiths has joined #bitcoin-core-dev
111 2016-07-20T01:32:12  *** Giszmo1 has joined #bitcoin-core-dev
112 2016-07-20T01:33:45  *** Giszmo has quit IRC
113 2016-07-20T01:42:42  *** aalex has quit IRC
114 2016-07-20T01:45:01  *** hsmiths has quit IRC
115 2016-07-20T01:45:24  *** aalex has joined #bitcoin-core-dev
116 2016-07-20T01:48:54  *** hsmiths has joined #bitcoin-core-dev
117 2016-07-20T01:49:05  *** netsin has quit IRC
118 2016-07-20T02:01:19  *** achow101 has quit IRC
119 2016-07-20T02:01:42  *** achow101 has joined #bitcoin-core-dev
120 2016-07-20T02:04:07  *** jcliff42 has joined #bitcoin-core-dev
121 2016-07-20T02:19:35  *** moli has joined #bitcoin-core-dev
122 2016-07-20T02:21:43  *** molz has quit IRC
123 2016-07-20T02:24:56  *** Chris_Stewart_5 has quit IRC
124 2016-07-20T02:27:58  *** Samdney has quit IRC
125 2016-07-20T02:34:43  *** gribble has quit IRC
126 2016-07-20T02:35:40  *** netsin has joined #bitcoin-core-dev
127 2016-07-20T02:38:56  *** gribble has joined #bitcoin-core-dev
128 2016-07-20T02:40:47  *** alpalp has quit IRC
129 2016-07-20T02:44:17  <GitHub106> [bitcoin] pstratem opened pull request #8377: Rename usdhd option to createhdwallet (master...2016-07-16-cwallet-createhdwallet) https://github.com/bitcoin/bitcoin/pull/8377
130 2016-07-20T02:44:52  *** Chris_Stewart_5 has joined #bitcoin-core-dev
131 2016-07-20T02:46:15  <phantomcircuit> jonasschnelli, fyi qa/rpc-tests/wallet-hd.py passes even when i changed usehd to createhdwallet
132 2016-07-20T02:46:30  <phantomcircuit> which means it's broken maybe?
133 2016-07-20T02:47:05  *** netsin has quit IRC
134 2016-07-20T02:48:04  <phantomcircuit> CHDChain & CKeyMetadata in walletdb.h seem like they could be in wallet.h instead
135 2016-07-20T02:48:14  <phantomcircuit> they're not really specific to the walletdb
136 2016-07-20T02:48:37  <phantomcircuit> otoh maybe it's reasonable that the abstraction be improved such that they are?
137 2016-07-20T02:51:45  *** aalex has quit IRC
138 2016-07-20T02:53:16  *** Chris_Stewart_5 has quit IRC
139 2016-07-20T02:54:43  *** jcliff42 has quit IRC
140 2016-07-20T02:55:21  *** aalex has joined #bitcoin-core-dev
141 2016-07-20T02:59:52  *** NicLin has quit IRC
142 2016-07-20T03:06:30  *** netsin has joined #bitcoin-core-dev
143 2016-07-20T03:08:16  *** Lightsword has quit IRC
144 2016-07-20T03:08:20  *** warren has quit IRC
145 2016-07-20T03:09:16  *** netsin has quit IRC
146 2016-07-20T03:09:49  *** TD-Linux has quit IRC
147 2016-07-20T03:11:21  *** warren has joined #bitcoin-core-dev
148 2016-07-20T03:12:56  *** Lightsword has joined #bitcoin-core-dev
149 2016-07-20T03:14:36  *** TD-Linux has joined #bitcoin-core-dev
150 2016-07-20T03:28:12  *** achow101 has quit IRC
151 2016-07-20T03:28:34  *** achow101 has joined #bitcoin-core-dev
152 2016-07-20T03:35:53  *** PRab has joined #bitcoin-core-dev
153 2016-07-20T03:53:50  <michagogo> Okay, PR created -- looks like it didn't happen automatically because GitHub moved their API endpoint, and my Octokit was outdated.
154 2016-07-20T04:22:26  <phantomcircuit> sipa: apparently returning a CKey doesn't work?
155 2016-07-20T04:22:36  *** moli has quit IRC
156 2016-07-20T04:23:48  <phantomcircuit> had to do this to 8375 https://gist.github.com/pstratem/a01c49e3be2a82076d240819e3823f31
157 2016-07-20T04:34:33  *** kadoban has quit IRC
158 2016-07-20T04:38:38  *** moli has joined #bitcoin-core-dev
159 2016-07-20T04:44:46  *** fengling has quit IRC
160 2016-07-20T05:13:05  *** fengling has joined #bitcoin-core-dev
161 2016-07-20T05:13:28  *** ebfull has joined #bitcoin-core-dev
162 2016-07-20T05:21:07  *** aalex has quit IRC
163 2016-07-20T05:25:20  *** aalex has joined #bitcoin-core-dev
164 2016-07-20T05:31:04  *** dirtynewshoes has quit IRC
165 2016-07-20T05:32:38  <GitHub9> [bitcoin] pstratem opened pull request #8378: Move SetMinVersion for FEATURE_HD to SetHDMasterKey (master...2016-07-19-cwallet-initloadwallet-ordering) https://github.com/bitcoin/bitcoin/pull/8378
166 2016-07-20T05:32:45  *** moli has quit IRC
167 2016-07-20T05:34:04  *** moli has joined #bitcoin-core-dev
168 2016-07-20T05:36:08  *** moli has joined #bitcoin-core-dev
169 2016-07-20T05:38:53  *** baldur has quit IRC
170 2016-07-20T05:47:08  *** moli has joined #bitcoin-core-dev
171 2016-07-20T05:51:19  *** baldur has joined #bitcoin-core-dev
172 2016-07-20T06:08:34  *** dirtynewshoes has joined #bitcoin-core-dev
173 2016-07-20T06:37:34  *** dirtynewshoes has quit IRC
174 2016-07-20T06:42:06  *** fengling has quit IRC
175 2016-07-20T06:44:41  *** fengling has joined #bitcoin-core-dev
176 2016-07-20T07:04:41  *** dirtynewshoes has joined #bitcoin-core-dev
177 2016-07-20T07:10:51  <GitHub21> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/045106b4f13c...c98abf2c7099
178 2016-07-20T07:10:51  <GitHub21> bitcoin/master 3b3ce25 Cory Fields: build: fix non-deterministic biplist...
179 2016-07-20T07:10:52  <GitHub21> bitcoin/master c98abf2 Wladimir J. van der Laan: Merge #8373: Fix OSX non-deterministic dmg...
180 2016-07-20T07:11:01  <GitHub99> [bitcoin] laanwj closed pull request #8373: Fix OSX non-deterministic dmg (master...biplist-determinism) https://github.com/bitcoin/bitcoin/pull/8373
181 2016-07-20T07:12:06  <GitHub168> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/1fe7f404078121ad370ec955aa23befa322549bb
182 2016-07-20T07:12:06  <GitHub168> bitcoin/0.13 1fe7f40 Cory Fields: build: fix non-deterministic biplist...
183 2016-07-20T07:15:48  <wumpus> BlueMatt: the only thing that would have blocked rc1 yesterday is a critical issue that causes everything to catch fire - if we keep regarding last-minute non-critical changes as blockers, we can never get anything released
184 2016-07-20T07:16:27  <wumpus> I agree it should be solved obviously
185 2016-07-20T07:27:07  *** Guyver2 has joined #bitcoin-core-dev
186 2016-07-20T07:42:07  *** Arnavion has quit IRC
187 2016-07-20T07:42:29  *** Arnavion has joined #bitcoin-core-dev
188 2016-07-20T07:46:14  <phantomcircuit> wumpus, updated the comment in #8378 think it needs to be tagged for 0.13
189 2016-07-20T07:50:21  <wumpus> tagged
190 2016-07-20T07:58:03  <Raccoon> +--------------+   +--------+   +-----+   +--------+   +------+   +------+   +---+  
191 2016-07-20T07:58:04  <Raccoon> | #BITCOIN-DEV |## | MISSES |-  | YOU |\\ | GAVIN, |## | COME |\\ | HOME |-  | ! |::
192 2016-07-20T07:58:04  <Raccoon> +--------------+## +--------+ | +-----+\\ +--------+## +------+\\ +------+ | +---+::
193 2016-07-20T07:58:04  <Raccoon>   ################   '--------    \\\\\\\   ##########   \\\\\\\\   '------    :::::
194 2016-07-20T07:59:06  <luke-jr> !ops
195 2016-07-20T07:59:12  *** ChanServ sets mode: +o luke-jr
196 2016-07-20T07:59:35  <luke-jr> eh, he's not here? O.o
197 2016-07-20T07:59:40  *** luke-jr sets mode: -o luke-jr
198 2016-07-20T08:00:18  <phantomcircuit> luke-jr, lol it's a notice and the modes are set wrong
199 2016-07-20T08:00:33  <luke-jr> phantomcircuit: modes are set "wrong" because that's how GitHub does commits :x
200 2016-07-20T08:00:50  <phantomcircuit> luke-jr, lol
201 2016-07-20T08:01:05  <phantomcircuit> i think you can still set a ban to keep him from doing it
202 2016-07-20T08:01:21  <luke-jr> hm
203 2016-07-20T08:02:23  <jl2012> the signed osx binary seems not deterministic?
204 2016-07-20T08:05:15  <wumpus> jl2012: no, the ds_store is not deterministic
205 2016-07-20T08:05:24  <wumpus> (which is not part of the signed data, but still affects the hash)
206 2016-07-20T08:05:50  <btcdrak> phantomcircuit: no you can set github to come to the channel to post commit notices
207 2016-07-20T08:06:14  <wumpus> see https://github.com/bitcoin/bitcoin/pull/8373
208 2016-07-20T08:09:21  <jl2012> wumpus: so I should now rebuild for osx?
209 2016-07-20T08:09:38  <wumpus> no, we'll just let this slide for rc1, for rc2 it will be solved
210 2016-07-20T08:10:07  <jl2012> ok
211 2016-07-20T08:10:08  <wumpus> (it's a change in the build system, not in the descriptor, so you can't easily build rc1 with that change)
212 2016-07-20T08:10:21  <kinlo> hmmmz
213 2016-07-20T08:10:46  <kinlo> this channel needs to be set +n (no messages from people not on the channel)
214 2016-07-20T08:10:59  <kinlo> just make the github clients join the channel
215 2016-07-20T08:11:08  <wumpus> then github can't paste into it
216 2016-07-20T08:11:15  <btcdrak> wumpus: yes it can
217 2016-07-20T08:11:15  <kinlo> github can join...
218 2016-07-20T08:11:19  <btcdrak> it's a setting
219 2016-07-20T08:11:38  <luke-jr> kinlo: way too spammy
220 2016-07-20T08:11:42  <wumpus> I know, we had that in the beginning, but then github bots will be joining and parting all the time
221 2016-07-20T08:11:55  <kinlo> luke-jr: and raccoon isn't ?:)
222 2016-07-20T08:12:04  <luke-jr> Raccoon can be banned if he does it again
223 2016-07-20T08:12:11  <luke-jr> he PM'd me he wouldn't
224 2016-07-20T08:12:20  <wumpus> they distribute it over multiple bots, let's just ban the idiot and move on
225 2016-07-20T08:12:55  *** ChanServ sets mode: +o wumpus
226 2016-07-20T08:13:10  *** wumpus sets mode: +b *!*@unaffiliated/raccoon
227 2016-07-20T08:13:17  *** ChanServ sets mode: -o wumpus
228 2016-07-20T08:15:31  *** davidlj95 has joined #bitcoin-core-dev
229 2016-07-20T08:24:53  *** Guyver2 has quit IRC
230 2016-07-20T08:31:41  <jonasschnelli> [23:45:16] <phantomcircuit:#bitcoin-core-dev> jonasschnelli, why does CHDKeyStore::PrivateKeyDerivation take the keypath as a string?
231 2016-07-20T08:31:58  <jonasschnelli> phantomcircuit: I guess you are refering to one of my closed PR Bip32 PRs?
232 2016-07-20T08:32:19  <jonasschnelli> I think somewhen we need a feature that can derive keys from a given string keypath.
233 2016-07-20T08:32:25  *** jannes has joined #bitcoin-core-dev
234 2016-07-20T08:32:45  <jonasschnelli> <*highlight>	[04:46:15] <phantomcircuit:#bitcoin-core-dev> jonasschnelli, fyi qa/rpc-tests/wallet-hd.py passes even when i changed usehd to createhdwallet
235 2016-07-20T08:33:02  <jonasschnelli> phantomcircuit: usehd=1 is default....
236 2016-07-20T08:37:30  *** MarcoFalke has joined #bitcoin-core-dev
237 2016-07-20T08:44:30  *** MarcoFalke has left #bitcoin-core-dev
238 2016-07-20T08:55:41  *** MarcoFalke has joined #bitcoin-core-dev
239 2016-07-20T09:04:32  *** pedrobranco has joined #bitcoin-core-dev
240 2016-07-20T09:05:03  *** pedrobranco has joined #bitcoin-core-dev
241 2016-07-20T09:06:57  *** MarcoFalke has left #bitcoin-core-dev
242 2016-07-20T09:18:06  *** fengling has quit IRC
243 2016-07-20T09:18:14  <jl2012> wumpus: v0 witness program scriptPubKey becomes standard before activation even in mainnet. Do we need to mention this in release notes?
244 2016-07-20T09:18:53  <jl2012> Now it says "Testnet-only segregated witness" but it affects some mainnet policy
245 2016-07-20T09:19:07  <wumpus> jl2012: does it affect users in any way, in practice?
246 2016-07-20T09:19:56  <wumpus> I mean does it result in something useful that can be done already? if not I don't think it needs to be mentioned
247 2016-07-20T09:20:13  <wumpus> it'll just confuse
248 2016-07-20T09:20:48  <jl2012> only if someone generates bare segwit outputs. 0.13 will relay and mine these transactions
249 2016-07-20T09:21:40  <wumpus> I don't understand, why is that the case for mainnet?
250 2016-07-20T09:22:17  <sipa> spending them is non-standard, and won't be relayed before activation
251 2016-07-20T09:22:23  <jl2012> because witness outputs are now starndard
252 2016-07-20T09:23:00  <jl2012> I'm not talking about spending. I'm talking about sending to segwit outputs
253 2016-07-20T09:24:17  <jl2012> precisely, if a scriptPubKey is OP_0 <20/32 bytes>, it becomes standard in 0.13
254 2016-07-20T09:25:35  <gmaxwell> He means paying to a segwit output which doesn't use p2sh.
255 2016-07-20T09:25:44  <jl2012> yes
256 2016-07-20T09:26:22  <gmaxwell> They can't be encoded as addresses currently, they can't be spent (well spending is nonstandard). but you could pay to them just like you could pay to a p2sh segwit address (even now)
257 2016-07-20T09:26:53  <wumpus> so, all in all, it's still useless right now
258 2016-07-20T09:26:55  <gmaxwell> I think perhaps we sould leave them non-standard in mainnet until there is an address encoding.
259 2016-07-20T09:27:14  <gmaxwell> because it's useless and allowing useless things get dumb behavior enshrined.
260 2016-07-20T09:27:38  <wumpus> yes - I guess they could be (mis)used for e.g. data storage?
261 2016-07-20T09:28:13  <wumpus> like bare multisig
262 2016-07-20T09:29:04  <gmaxwell> not really any worse than p2pkh, (well 32 bytes instead of 20); but right now _any_ use is either going to be a mistake or something stupid.
263 2016-07-20T09:29:54  <jl2012> gmaxwell: I think even LN clients will use p2sh-segwit until there is a new address format?
264 2016-07-20T09:30:41  <jl2012> technically speaking, people could use native segwit with BIP70
265 2016-07-20T09:30:56  <sipa> right
266 2016-07-20T09:31:30  <wumpus> I'm not sure standardness is meant as a way to prevent people from doing something stupid if they try very hard
267 2016-07-20T09:31:36  *** btcfan has joined #bitcoin-core-dev
268 2016-07-20T09:31:41  <wumpus> I think just not mentioning this is enough to have no one care about it
269 2016-07-20T09:31:56  <michagogo> There seems to be some unintentional markup going on here. https://usercontent.irccloud-cdn.com/file/1WImycPE/IMG_0002.PNG
270 2016-07-20T09:32:27  <gmaxwell> jl2012: yea, but not on a network without any segwit support-- fair that I should back that until segwit is working.
271 2016-07-20T09:32:30  <wumpus> michagogo: looks like a line starting with #
272 2016-07-20T09:32:52  <michagogo> wumpus: yep, makes sense
273 2016-07-20T09:33:04  <sipa> michagogo: yeah, the line need rewrapping
274 2016-07-20T09:33:15  <michagogo> (That's the 0.13 release notes)
275 2016-07-20T09:33:20  <gmaxwell> as an aside, in the future new segwit script types should remain non-standard until a non-trivial number of blocks after activation to avoid people getting themselves pilfered from in a reorg.
276 2016-07-20T09:34:52  <sipa> should we do that even for segwit relay now?
277 2016-07-20T09:34:52  *** pedrobranco has quit IRC
278 2016-07-20T09:35:14  *** pedrobranco has joined #bitcoin-core-dev
279 2016-07-20T09:36:59  *** pedrobranco has quit IRC
280 2016-07-20T09:37:09  <gmaxwell> the concern is that the feature activates and then right at that block some genius starts paying to it, then there is a 1 block reorg and their coins are stolen by the new block right before activation.
281 2016-07-20T09:37:13  *** pedrobranco has joined #bitcoin-core-dev
282 2016-07-20T09:39:11  *** pedrobranco has quit IRC
283 2016-07-20T09:39:40  <gmaxwell> obviously "don't do that" but it's pretty surprising, and even some experts have thought that the 2016 block quiet period in the activation would prevent that concern.
284 2016-07-20T09:40:06  <sipa> well it's a one-line change
285 2016-07-20T09:40:25  <sipa> check bip9 status at tip.GetAncestor(144) instead of at tip
286 2016-07-20T09:40:39  <sipa> if you want a day delay
287 2016-07-20T09:41:07  *** pedrobranco has joined #bitcoin-core-dev
288 2016-07-20T09:48:02  <gmaxwell> well we're not even triggering relay of output creation on activation now.
289 2016-07-20T09:48:30  <gmaxwell> (and we can't for p2sh, but I suppose there a potential attacker wouldn't usually know the preimage)
290 2016-07-20T09:48:56  <GitHub102> [bitcoin] jl2012 opened pull request #8379: Remove duplicated name in release notes (0.13...patch-14) https://github.com/bitcoin/bitcoin/pull/8379
291 2016-07-20T09:51:25  <GitHub109> [bitcoin] laanwj closed pull request #8379: Remove duplicated name in release notes (0.13...patch-14) https://github.com/bitcoin/bitcoin/pull/8379
292 2016-07-20T09:51:26  <GitHub104> [bitcoin] laanwj pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/1fe7f4040781...f0ff08d7841c
293 2016-07-20T09:51:27  <GitHub104> bitcoin/0.13 48b9208 Johnson Lau: Remove duplicated name in release notes
294 2016-07-20T09:51:27  <GitHub104> bitcoin/0.13 f0ff08d Wladimir J. van der Laan: Merge #8379: Remove duplicated name in release notes...
295 2016-07-20T09:57:55  <GitHub113> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c98abf2c7099...8e048f40cc25
296 2016-07-20T09:57:55  <GitHub113> bitcoin/master 6523fca Patrick Strateman: Move SetMinVersion for FEATURE_HD to SetHDMasterKey
297 2016-07-20T09:57:56  <GitHub113> bitcoin/master 8e048f4 Wladimir J. van der Laan: Merge #8378: [Wallet]Move SetMinVersion for FEATURE_HD to SetHDMasterKey...
298 2016-07-20T09:58:05  <GitHub114> [bitcoin] laanwj closed pull request #8378: [Wallet]Move SetMinVersion for FEATURE_HD to SetHDMasterKey (master...2016-07-19-cwallet-initloadwallet-ordering) https://github.com/bitcoin/bitcoin/pull/8378
299 2016-07-20T09:58:30  <GitHub11> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/ebea65121e6c62f6b6acd79408a681b987126a0d
300 2016-07-20T09:58:30  <GitHub11> bitcoin/0.13 ebea651 Patrick Strateman: Move SetMinVersion for FEATURE_HD to SetHDMasterKey...
301 2016-07-20T10:07:12  <btcdrak> My Pine64 with 2GB just finished a full sync, I started it Jul 14 00:45 UTC, and it finished Jul 20 09:55 UTC
302 2016-07-20T10:14:41  *** fengling has joined #bitcoin-core-dev
303 2016-07-20T10:15:06  <jannes> On topic of typos in release notes: "propagation relay" should be "propagation delay", I think.
304 2016-07-20T10:16:19  *** MarcoFalke has joined #bitcoin-core-dev
305 2016-07-20T10:16:33  <MarcoFalke> jannes: Pull request welcome :)
306 2016-07-20T10:17:57  <sipa> jannes: indeed!
307 2016-07-20T10:17:57  *** pedrobranco has quit IRC
308 2016-07-20T10:19:26  *** fengling has quit IRC
309 2016-07-20T10:21:19  *** pedrobranco has joined #bitcoin-core-dev
310 2016-07-20T10:25:50  <jonasschnelli> btcdrak: nice! What block storage did you use? SDCard or USBStick? Did you had a corruption(s) during sync?
311 2016-07-20T10:28:06  <btcdrak> jonasschnelli: I used a Samsung EVO+ 128MB, no corruption issues.
312 2016-07-20T10:28:51  <jonasschnelli> btcdrak: Okay. I guess the bigger the SDCard space the less corruptions you will see (even if you don't use the space).
313 2016-07-20T10:28:56  <jonasschnelli> Did you used prunining?
314 2016-07-20T10:29:13  <btcdrak> jonasschnelli: No, no pruning. Full node.
315 2016-07-20T10:29:31  <jonasschnelli> Technically with pruning its still a full node. :)
316 2016-07-20T10:29:40  <jonasschnelli> Good to know.. I need to try the same on my Pine.
317 2016-07-20T10:29:47  <btcdrak> jonasschnelli: It's a fuller node :-p
318 2016-07-20T10:29:52  <jonasschnelli> ;-)
319 2016-07-20T10:30:32  <jonasschnelli> We should sell Pine64 together with a nice case and some webbase control center for 50$ as "your bank at home".
320 2016-07-20T10:31:04  *** Cory has quit IRC
321 2016-07-20T10:33:19  <GitHub70> [bitcoin] jafaber opened pull request #8380: fix typo: propagation relay -> delay (0.13...patch-1) https://github.com/bitcoin/bitcoin/pull/8380
322 2016-07-20T10:35:26  <jannes> MarcoFalke: sipa: Created pull request. I know git, but first time I use github. Took me a while, sorry if it's duplicate by now :)
323 2016-07-20T10:37:34  *** jl2012 has quit IRC
324 2016-07-20T10:39:05  *** jl2012 has joined #bitcoin-core-dev
325 2016-07-20T10:39:54  <sipa> jannes: looks good
326 2016-07-20T10:45:44  *** laurentmt has joined #bitcoin-core-dev
327 2016-07-20T10:48:04  *** laurentmt has quit IRC
328 2016-07-20T10:48:05  *** pedrobranco has quit IRC
329 2016-07-20T10:48:11  *** pedrobranco has joined #bitcoin-core-dev
330 2016-07-20T10:50:25  *** pedrobra_ has joined #bitcoin-core-dev
331 2016-07-20T10:50:25  *** pedrobranco has quit IRC
332 2016-07-20T10:52:19  *** laurentmt has joined #bitcoin-core-dev
333 2016-07-20T10:52:19  *** pedrobra_ has quit IRC
334 2016-07-20T10:52:34  *** pedrobranco has joined #bitcoin-core-dev
335 2016-07-20T10:54:36  *** laurentmt has quit IRC
336 2016-07-20T10:54:36  *** pedrobranco has quit IRC
337 2016-07-20T10:54:38  *** pedrobra_ has joined #bitcoin-core-dev
338 2016-07-20T10:56:32  *** pedrobra_ has quit IRC
339 2016-07-20T10:56:57  *** pedrobranco has joined #bitcoin-core-dev
340 2016-07-20T10:58:58  *** pedrobra_ has joined #bitcoin-core-dev
341 2016-07-20T10:58:58  *** pedrobranco has quit IRC
342 2016-07-20T11:00:57  *** pedrobranco has joined #bitcoin-core-dev
343 2016-07-20T11:00:57  *** pedrobra_ has quit IRC
344 2016-07-20T11:01:25  *** YOU-JI has joined #bitcoin-core-dev
345 2016-07-20T11:03:00  *** pedrobra_ has joined #bitcoin-core-dev
346 2016-07-20T11:03:00  *** pedrobranco has quit IRC
347 2016-07-20T11:04:38  *** pedrobra_ has quit IRC
348 2016-07-20T11:05:02  *** pedrobranco has joined #bitcoin-core-dev
349 2016-07-20T11:11:08  *** Cory has joined #bitcoin-core-dev
350 2016-07-20T11:16:14  *** fengling has joined #bitcoin-core-dev
351 2016-07-20T11:21:06  *** fengling has quit IRC
352 2016-07-20T11:28:03  *** davidlj95 has left #bitcoin-core-dev
353 2016-07-20T11:28:17  *** cryptapus has joined #bitcoin-core-dev
354 2016-07-20T11:28:17  *** cryptapus has joined #bitcoin-core-dev
355 2016-07-20T11:32:51  *** davec has quit IRC
356 2016-07-20T11:38:31  *** davec has joined #bitcoin-core-dev
357 2016-07-20T11:38:58  *** Ylbam has joined #bitcoin-core-dev
358 2016-07-20T11:52:43  *** pedrobranco has quit IRC
359 2016-07-20T11:52:43  *** pedrobra_ has joined #bitcoin-core-dev
360 2016-07-20T11:57:02  *** pedrobranco has joined #bitcoin-core-dev
361 2016-07-20T11:57:02  *** pedrobra_ has quit IRC
362 2016-07-20T11:58:34  *** moli has quit IRC
363 2016-07-20T12:03:55  *** pedrobranco has quit IRC
364 2016-07-20T12:04:04  *** pedrobranco has joined #bitcoin-core-dev
365 2016-07-20T12:15:11  <GitHub65> [bitcoin] jl2012 opened pull request #8381: Make witness v0 outputs non-standard (master...patch-15) https://github.com/bitcoin/bitcoin/pull/8381
366 2016-07-20T12:18:05  *** fengling has joined #bitcoin-core-dev
367 2016-07-20T12:23:06  *** fengling has quit IRC
368 2016-07-20T12:27:04  *** pedrobranco has quit IRC
369 2016-07-20T12:35:14  *** pedrobranco has joined #bitcoin-core-dev
370 2016-07-20T12:48:28  *** Chris_Stewart_5 has joined #bitcoin-core-dev
371 2016-07-20T13:03:13  <GitHub128> [bitcoin] jonasschnelli closed pull request #6481: [mining] allow other signal listeners to provide scripts for mining (master...2015/07/enhance_mining_flexibility) https://github.com/bitcoin/bitcoin/pull/6481
372 2016-07-20T13:14:47  <Chris_Stewart_5> sipa: I'm looking closer at CBloomFilter, and does nHashFuncs/nTweak need to be prefaced with a compact size int as well? https://github.com/bitcoin/bitcoin/blob/f17032f703288d43a76cffe8fa89b87ade9e3074/src/bloom.h#L50
373 2016-07-20T13:15:04  <Chris_Stewart_5> Can't an 'unsigned int' be larger than 4 bytes?
374 2016-07-20T13:15:06  *** adamg has quit IRC
375 2016-07-20T13:15:44  <sipa> Chris_Stewart_5: no, they're just integers
376 2016-07-20T13:16:01  <sipa> Chris_Stewart_5: READWRITE(x) just invokes the serializer/deserializer for x
377 2016-07-20T13:16:25  <sipa> vectors are serialized as compactsize(vector.size()), and then a concatenation of all the elements
378 2016-07-20T13:16:50  <sipa> and no, the serialization code (so far) relies on unsigned int being 4 bytes
379 2016-07-20T13:19:27  *** fengling has joined #bitcoin-core-dev
380 2016-07-20T13:19:44  *** laurentmt has joined #bitcoin-core-dev
381 2016-07-20T13:20:53  <Chris_Stewart_5> Hmm some how I got in my head that 'unsigned int' size isn't constant, looks like I was wrong
382 2016-07-20T13:21:44  <sipa> the C standard does not fix its size
383 2016-07-20T13:21:59  <sipa> but we don't support any architectures where it isn't 4 bytes
384 2016-07-20T13:22:48  <Chris_Stewart_5> oh ok, thanks for the clarification
385 2016-07-20T13:24:26  *** fengling has quit IRC
386 2016-07-20T14:07:20  *** YOU-JI has quit IRC
387 2016-07-20T14:10:03  *** pedrobranco has quit IRC
388 2016-07-20T14:10:41  *** pedrobranco has joined #bitcoin-core-dev
389 2016-07-20T14:12:45  *** monkey_trauma has joined #bitcoin-core-dev
390 2016-07-20T14:20:55  *** fengling has joined #bitcoin-core-dev
391 2016-07-20T14:24:33  *** zooko has joined #bitcoin-core-dev
392 2016-07-20T14:25:46  *** fengling has quit IRC
393 2016-07-20T14:29:29  *** moli has joined #bitcoin-core-dev
394 2016-07-20T14:32:10  *** kadoban has joined #bitcoin-core-dev
395 2016-07-20T14:32:59  *** frankenmint has joined #bitcoin-core-dev
396 2016-07-20T14:56:08  *** owowo has quit IRC
397 2016-07-20T15:03:08  *** zooko has quit IRC
398 2016-07-20T15:12:04  *** Chris_Stewart_5 has quit IRC
399 2016-07-20T15:16:12  *** owowo has joined #bitcoin-core-dev
400 2016-07-20T15:21:12  *** Amnez777 has joined #bitcoin-core-dev
401 2016-07-20T15:21:55  *** harrymm has quit IRC
402 2016-07-20T15:22:27  *** fengling has joined #bitcoin-core-dev
403 2016-07-20T15:27:13  *** Chris_Stewart_5 has joined #bitcoin-core-dev
404 2016-07-20T15:27:26  *** fengling has quit IRC
405 2016-07-20T15:41:05  *** harrymm has joined #bitcoin-core-dev
406 2016-07-20T15:49:38  *** laurentmt has quit IRC
407 2016-07-20T15:50:30  *** netsin has joined #bitcoin-core-dev
408 2016-07-20T15:59:08  *** pedrobranco has quit IRC
409 2016-07-20T16:01:34  *** pedrobranco has joined #bitcoin-core-dev
410 2016-07-20T16:16:39  *** Guyver2 has joined #bitcoin-core-dev
411 2016-07-20T16:23:55  *** fengling has joined #bitcoin-core-dev
412 2016-07-20T16:28:46  *** fengling has quit IRC
413 2016-07-20T16:34:39  *** aalex has quit IRC
414 2016-07-20T16:35:24  *** aalex has joined #bitcoin-core-dev
415 2016-07-20T16:37:18  <GitHub104> [bitcoin] dooglus opened pull request #8382: Fix formatting error (0.13...patch-4) https://github.com/bitcoin/bitcoin/pull/8382
416 2016-07-20T16:50:10  <bsm117532> When using `signrawtransaction` on a witness output and the relevant privkey isn't known to bitcoind, it gives an erroneous error message: "Witness program hash mismatch".
417 2016-07-20T16:52:38  *** zooko has joined #bitcoin-core-dev
418 2016-07-20T16:52:56  <sipa> bsm117532: is the witness script known?
419 2016-07-20T16:53:10  <sipa> ah, or it's p2wpkh
420 2016-07-20T16:58:53  <bsm117532> It's p2wpkh
421 2016-07-20T17:00:09  <bsm117532> I bet I'm the only person using *raw* rpc calls with witness txns ;-)
422 2016-07-20T17:00:26  <instagibbs> bsm117532, that error should only pop up if it fails VerifyScript?
423 2016-07-20T17:03:16  <bsm117532> instagibbs: Is it that it fails to find a key, so fails to sign it...then fails VerifyScript at the end of the function?
424 2016-07-20T17:03:33  <bsm117532> I'd think this wouldn't be a failure but should spit out the same transaction with "complete": false
425 2016-07-20T17:03:37  <instagibbs> looks like the error for p2wpkh is just checking if the stack is size 2?
426 2016-07-20T17:03:44  <instagibbs> if the hash it seems is size 20
427 2016-07-20T17:03:47  <instagibbs> sees*
428 2016-07-20T17:04:20  <instagibbs> https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L1323
429 2016-07-20T17:04:30  <instagibbs> and a few lines before it, for the 32 byte case
430 2016-07-20T17:06:49  <bsm117532> instagibbs: Yes, that's it. The witness stack size would be zero (because it's unsigned).
431 2016-07-20T17:07:12  <instagibbs> ok so it pushes nothing, and fails later
432 2016-07-20T17:09:01  *** pedrobranco has quit IRC
433 2016-07-20T17:10:29  <instagibbs> we should just be checking the return value of ProduceSignature, right?
434 2016-07-20T17:10:40  <bsm117532> SCRIPT_ERR_WITNESS_PROGRAM_WITNESS_EMPTY is a better error if stack is empty
435 2016-07-20T17:12:49  <instagibbs> it's a special case for p2wpkh
436 2016-07-20T17:12:54  <instagibbs> not a great error message I agree though
437 2016-07-20T17:13:10  * bsm117532 is still trying to grok the VerifyScript line
438 2016-07-20T17:14:30  <bsm117532> This loop calls VerifyScript after each vin it processes.  So with multiple inputs, it will always fail, even if it can sign the txn!
439 2016-07-20T17:14:42  <bsm117532> (My example only has one input)
440 2016-07-20T17:15:44  <bsm117532> What happens with non-segwit p2pkh's here?  Won't they fail too?
441 2016-07-20T17:15:58  *** pedrobranco has joined #bitcoin-core-dev
442 2016-07-20T17:16:06  <instagibbs> hmm? why would it fail with multiple valid inputs?
443 2016-07-20T17:16:19  <bsm117532> Because it signs them one at a time.
444 2016-07-20T17:16:23  <instagibbs> they will fail as well, the error here i think is just not helpful
445 2016-07-20T17:16:27  <bsm117532> And calls verifyscript after each one
446 2016-07-20T17:16:33  <instagibbs> that's how signing works
447 2016-07-20T17:17:13  <bsm117532> So if I read this correctly, signrawtransaction would be incapable of signing something with multiple unsigned inputs?
448 2016-07-20T17:17:29  <instagibbs> No, it signs anything it can
449 2016-07-20T17:18:19  <instagibbs> then checks that script to see if it's satisfied
450 2016-07-20T17:18:34  <instagibbs> in our case it's not, but it needs to spit out a better error
451 2016-07-20T17:18:43  <bsm117532> The VerifyScript is inside the loop though...
452 2016-07-20T17:18:51  <bsm117532> It should be outside.
453 2016-07-20T17:19:41  <instagibbs> No, each input scriptSig needs to be checked individually
454 2016-07-20T17:20:03  <bsm117532> Oh I see, `i` is passed.
455 2016-07-20T17:22:32  <bsm117532> Does anyone have a good WIP to incorporate that change?  I can fix it with my segwit wallet improvements if not.
456 2016-07-20T17:25:33  *** fengling has joined #bitcoin-core-dev
457 2016-07-20T17:25:40  *** Chris_Stewart_5 has quit IRC
458 2016-07-20T17:27:38  *** Chris_Stewart_5 has joined #bitcoin-core-dev
459 2016-07-20T17:30:26  *** fengling has quit IRC
460 2016-07-20T17:30:58  <instagibbs> bsm117532, it is true that the 32 byte version has an error already for empty witness
461 2016-07-20T17:32:24  <instagibbs> seems useful as a debugging message for both
462 2016-07-20T17:32:37  <bsm117532> If I read this correctly, `signrawtransaction` cannot produce a transaction such that "complete": false.  That behavior is fine, if a little confusing.  I can just give the other error message (witness program empty) instead.
463 2016-07-20T17:34:44  <sipa> sure, the result of signrawtransaction can be complete:false ?
464 2016-07-20T17:35:02  <sipa> for example in case of multisig and you only have some of the keys
465 2016-07-20T17:35:38  <bsm117532> I agree that's logically what it *should* do, but that VerifyScript called for each input fails if it's unsigned.
466 2016-07-20T17:35:44  <bsm117532> I could be reading it wrong though...
467 2016-07-20T17:36:50  <sipa> where did you see this error, btw?
468 2016-07-20T17:37:14  <bsm117532> Running: bitcoin-cli signrawtransaction
469 2016-07-20T17:37:35  <bsm117532> for a key that isn't in my wallet.  It's a simple one input, one output txn, both p2wpkh
470 2016-07-20T17:37:38  <sipa> hmm, that should never return an error
471 2016-07-20T17:37:45  <sipa> it should just not sign
472 2016-07-20T17:41:37  <bsm117532> It appears that TransactionSignatureChecker should be checking a witness signature, but STANDARD_SCRIPT_VERIFY_FLAGS contains SCRIPT_VERIFY_WITNESS which causes VerifyScript to fail if the witness is absent.
473 2016-07-20T17:42:25  <bsm117532> Could we remove SCRIPT_VERIFY_WITNESS from this call? https://github.com/bitcoin/bitcoin/blob/master/src/rpc/rawtransaction.cpp#L821
474 2016-07-20T17:44:04  <sipa> i don't understand why we call that in the first place
475 2016-07-20T17:44:21  <sipa> the only correctness check should be at the end, to determine the value of complete
476 2016-07-20T17:44:35  <bsm117532> sipa: I agree
477 2016-07-20T17:44:37  <instagibbs> "value of complete"?
478 2016-07-20T17:44:55  <bsm117532> instagibbs pointed out that it's a per-input check...
479 2016-07-20T17:46:04  *** Samdney has joined #bitcoin-core-dev
480 2016-07-20T17:46:20  <instagibbs> bsm117532, did you get back a partially signed txn?
481 2016-07-20T17:46:43  <bsm117532> instagibbs: no, it fails.  I'll pastebin it for  you
482 2016-07-20T17:46:49  <instagibbs> please do thanks
483 2016-07-20T17:47:23  <bsm117532> https://www.zerobin.net/?c6f94fa664089370#rWaua+D/pcl0zvYh8DNwbjfh+XitXfJSNHEOHLscb+A=
484 2016-07-20T17:47:33  <instagibbs> "hex"
485 2016-07-20T17:47:37  <instagibbs> that's the partially signed
486 2016-07-20T17:48:06  <bsm117532> Well it's not signed -- only one input.
487 2016-07-20T17:48:10  <instagibbs> errr, yes
488 2016-07-20T17:48:20  <instagibbs> but that's expected behavior if you don't have the key
489 2016-07-20T17:48:26  <instagibbs> (potentially partially signed)
490 2016-07-20T17:49:04  <bsm117532> Ok, like I said above, that's a reasonable behavior if it can't sign at all, in which case we can just change the error message.
491 2016-07-20T17:49:12  <instagibbs> kk, agreed
492 2016-07-20T17:49:31  *** Chris_Stewart_5 has quit IRC
493 2016-07-20T17:49:42  <bsm117532> Now how to get it to say "I don't have the keys..."  ;-)
494 2016-07-20T17:50:17  <instagibbs> I think just add the 0 size check like the p2wsh has.
495 2016-07-20T17:50:41  <bsm117532> Yes, I did that.  Will include it in my wallet updates.  Thanks!
496 2016-07-20T17:50:47  <instagibbs> schweet
497 2016-07-20T17:51:15  <instagibbs> do we want to augment TxInErrorToJSON to include witness data as hex?
498 2016-07-20T17:52:02  <instagibbs> for a p2w{pkh/sh} we'll be given a blank scriptSig and nothing else
499 2016-07-20T17:52:11  <bsm117532> Maybe...the error message is still unclear as to why it failed.
500 2016-07-20T17:52:41  <bsm117532> BTW one thing I want to add is when it displays the witness_v0_keyhash scriptPubKey...I'd like it to decode and print the corresponding p2wpkh address...
501 2016-07-20T17:56:46  *** Chris_Stewart_5 has joined #bitcoin-core-dev
502 2016-07-20T17:58:08  *** pedrobranco has quit IRC
503 2016-07-20T17:59:01  *** ebfull has quit IRC
504 2016-07-20T18:00:08  *** MarcoFalke has left #bitcoin-core-dev
505 2016-07-20T18:01:15  *** pedrobranco has joined #bitcoin-core-dev
506 2016-07-20T18:01:16  *** laurentmt has joined #bitcoin-core-dev
507 2016-07-20T18:04:29  *** laurentmt has quit IRC
508 2016-07-20T18:04:32  <arubi> bsm117532, which address?  the hash160(pubkey)?
509 2016-07-20T18:05:17  <bsm117532> Yes.  It's a simple change to ExtractDestination.
510 2016-07-20T18:05:27  <arubi> bsm117532, fwiw, I vaguely remember adding "|| (whichtype == TX_WITNESS_V0_KEYHASH)" to 'ExtractDestination()' in standard.cpp to make that happen with decodescript, but really I just did it for debugging.
511 2016-07-20T18:05:31  <bsm117532> I don't think we can know the destination for P2WPKH though since it uses a 32 bit hash...
512 2016-07-20T18:05:31  <arubi> ah yea ^
513 2016-07-20T18:05:37  *** pedrobranco has quit IRC
514 2016-07-20T18:05:53  <bsm117532> arubi: That's exactly what I just did, compiling now... ;-)
515 2016-07-20T18:06:28  <arubi> it should work :), but I don't know if it's a sane thing to show a user.. it doesn't really mean anything
516 2016-07-20T18:06:40  <bsm117532> Why not?
517 2016-07-20T18:07:03  *** Chris_Stewart_5 has quit IRC
518 2016-07-20T18:07:15  <arubi> because a version 1 address is not something a person that expects payment to a witness script should look for, even though it's probably done by default
519 2016-07-20T18:07:56  <arubi> or, maybe it does have its uses
520 2016-07-20T18:08:43  <arubi> I'm not sure.  I thought maybe someone would want to sign a message with that key, but really the other side needs to know how to handle witness v0 too to parse that..
521 2016-07-20T18:08:44  <bsm117532> I don't understand...the address in the scriptPubKey is the actual destination, and is consensus enforced, no?
522 2016-07-20T18:09:08  <arubi> I don't understand the question, sorry
523 2016-07-20T18:09:52  <arubi> what I mean is that a 1... address is a script, p2pkh.  why would a person looking at a witness v0 script want to see a 1.. address?
524 2016-07-20T18:09:58  <bsm117532> arubi: The withss_v0_keyhash address is the actual destionation, no?  What would be wrong with printing the address in base58 instead of the hex hash160?
525 2016-07-20T18:10:19  <arubi> there is no actual address for a witness v0 script, at least afaik
526 2016-07-20T18:11:04  <bsm117532> Sure there is, it's that one in the scriptPubKey...unless I'm horribly confused.
527 2016-07-20T18:11:35  <arubi> you mean 0x00 0x14 0x<hash160> ?
528 2016-07-20T18:11:41  <bsm117532> Yes
529 2016-07-20T18:12:00  <arubi> that has no address pattern that I know of, I might be wrong
530 2016-07-20T18:12:37  <bsm117532> My tiny patch does this: https://www.zerobin.net/?ad6eb3578c41e566#Sy4WYHvXEqVGSD3+raknP1SfNUzN+KC9AsejLzSIReI=
531 2016-07-20T18:12:49  <arubi> right, that's what I did.
532 2016-07-20T18:13:08  <bsm117532> What's wrong with this address msFV...?
533 2016-07-20T18:13:17  <arubi> it's a p2pkh script address
534 2016-07-20T18:13:58  <bsm117532> So?  it's the corresponding input that determines that a segregated witness needs to be used, not the address itself.
535 2016-07-20T18:13:59  <arubi> it might help with referencing the private key, because that's how core works, but nothing else
536 2016-07-20T18:15:04  <arubi> I agree that it has some value to a power user, but it's confusing at best to anyone else
537 2016-07-20T18:15:35  <bsm117532> How could it possibly be confusing?  Is there any chance that the privkey corresponding to msFV... does not control the sent funds?
538 2016-07-20T18:16:06  <bsm117532> This scriptPubKey is the only indicator of the destination address...
539 2016-07-20T18:16:14  <arubi> it's not about that, listing that address will make folks accidentally accept payments to both v0 witnesses /and/ that p2pkh script
540 2016-07-20T18:17:27  <bsm117532> The new address types BIP for segwit was deferred.  I don't fully understand that...
541 2016-07-20T18:17:41  <arubi> there is no address type for v0 and v0 witnesses
542 2016-07-20T18:17:56  <bsm117532> So some users are going to have segwit payments and their wallet doesn't know how to spend it, you're saying, because they didn't upgrade their wallet?
543 2016-07-20T18:17:56  <arubi> er, v0/v1
544 2016-07-20T18:18:05  *** pedrobranco has joined #bitcoin-core-dev
545 2016-07-20T18:18:27  <arubi> no one is going to accept payments to segwit scripts unless they actually know what they're doing, at least at first
546 2016-07-20T18:19:01  <bsm117532> Sure
547 2016-07-20T18:19:09  <arubi> bsm117532, the correct way now is to wrap it in a p2sh
548 2016-07-20T18:19:46  <bsm117532> Well without this decoding step, `decoderawtransaction` gives absolutely no indication of the destination...which is why I want to decode it.  :-P
549 2016-07-20T18:19:51  <instagibbs> bsm117532, im working on a small PR to print out witness data when errors occur in signing
550 2016-07-20T18:20:12  <bsm117532> arubi: FWIW I'm building an application that will be segwit-only.
551 2016-07-20T18:20:19  <bsm117532> instagibbs: cool
552 2016-07-20T18:20:34  <arubi> bsm117532, what do you need a 1... address for then? :)
553 2016-07-20T18:21:23  <bsm117532> arubi: I'm rather confused.  A 1...address could be either P2PKH or P2WPKH depending on how the sender encodes the witness data, no?
554 2016-07-20T18:21:35  <arubi> no no
555 2016-07-20T18:21:52  <arubi> a p2wpkh has no address type.  when it gets one, /that/ should be listed in "addresses"
556 2016-07-20T18:22:25  *** Chris_Stewart_5 has joined #bitcoin-core-dev
557 2016-07-20T18:22:40  *** pedrobranco has quit IRC
558 2016-07-20T18:23:17  <arubi> bsm117532, a 1... address is the script "0x76 0xa9 0x14 0x<hash160> 0x88 0xac", it's "noise" coming out of decodescript for a v0 witness
559 2016-07-20T18:23:23  <bsm117532> So I've been sending funds to P2PKH (hash160) addresses, with segregated witness, and it works fine!
560 2016-07-20T18:23:41  <bsm117532> Oh I see what you're saying
561 2016-07-20T18:24:08  <arubi> well a v0 witness has a scriptcode just like a p2pkh script, so it verifies the same
562 2016-07-20T18:24:31  <bsm117532> arubi: No, a 1...address is a version byte concatenated with the hash160...
563 2016-07-20T18:24:47  <bsm117532> and the segregated witness verifies the hash160.
564 2016-07-20T18:24:48  <arubi> that's just the encoding, not the actual payment script
565 2016-07-20T18:25:08  <bsm117532> Sure
566 2016-07-20T18:25:13  <arubi> no, it actually does a p2pkh verification.  hash(pubkey) == hash && scriptsig & pubkey
567 2016-07-20T18:25:19  <bsm117532> Yes
568 2016-07-20T18:25:28  <bsm117532> Yes the script is implicit.
569 2016-07-20T18:25:40  <arubi> but not the address encoding
570 2016-07-20T18:26:02  <arubi> the 1.. address encoding is not the correct output.  an eventual v0 script address is
571 2016-07-20T18:26:18  <arubi> v0 witness*
572 2016-07-20T18:27:00  *** fengling has joined #bitcoin-core-dev
573 2016-07-20T18:27:15  <bsm117532> So there is an intent to bring BIP 142 and new address types (eventually) then?
574 2016-07-20T18:27:42  <arubi> I don't know.  I hope there will be, so people could use it
575 2016-07-20T18:28:01  <arubi> p2wsh(p2pk) is what you want now for about the same functionality
576 2016-07-20T18:28:05  <bsm117532> To be clear, I can create and spend P2WPKH funds on testnet, now.
577 2016-07-20T18:28:11  <instagibbs> bsm117532, sipa has been working on better address schemes. Not sure when he'll be "done" though :)
578 2016-07-20T18:28:17  <bsm117532> I see
579 2016-07-20T18:28:48  <arubi> yes, spend to bare sigs and redeem them, it's all possible. but a simple wallet couldn't send /to/ you
580 2016-07-20T18:28:55  <arubi> bare scripts*
581 2016-07-20T18:30:14  <bsm117532> FYI, `decoderawtransaction` DOES decode V0 witness addresses as I wanted to do above.
582 2016-07-20T18:31:46  *** fengling has quit IRC
583 2016-07-20T18:31:48  <arubi> now after the patch, or before? :)
584 2016-07-20T18:32:08  <bsm117532> now
585 2016-07-20T18:32:15  <bsm117532> Oh....
586 2016-07-20T18:32:45  <arubi> it's amazing how we've now both walked the same path :P
587 2016-07-20T18:32:59  <bsm117532> Hahaa you're right my patch changed that output.
588 2016-07-20T18:35:11  *** zooko has quit IRC
589 2016-07-20T18:35:42  <bsm117532> Ah, then, this is a problem.  I need bitcoind to track successive P2WPKH spends...and it's not doing it: "Invalid or non-wallet transaction id".  And, adding the P2PKH address doesn't help (thanks arubi, now I see why)
590 2016-07-20T18:36:50  <arubi> cheers bsm117532
591 2016-07-20T18:38:40  <bsm117532> I guess what I need to do is to get bitcoind to add a single txn to its txindex.  (Or use P2SH embedding)
592 2016-07-20T18:40:04  <GitHub69> [bitcoin] jonasschnelli pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/ebea65121e6c...66dde4edf733
593 2016-07-20T18:40:04  <GitHub69> bitcoin/0.13 ea91961 Chris Moore: Fix formatting error...
594 2016-07-20T18:40:05  <GitHub69> bitcoin/0.13 66dde4e Jonas Schnelli: Merge #8382: Fix formatting error...
595 2016-07-20T18:40:06  <GitHub22> [bitcoin] jonasschnelli closed pull request #8382: Fix formatting error (0.13...patch-4) https://github.com/bitcoin/bitcoin/pull/8382
596 2016-07-20T18:42:46  <arubi> why not p2sh(p2wsh({p2pk,multisig})) ? much more versatile
597 2016-07-20T18:44:29  <bsm117532>  I'm trying to be efficient and this is a non-wallet usage. ;-)
598 2016-07-20T18:44:36  <bsm117532> Also, learn segwit by fire...
599 2016-07-20T18:46:14  <bsm117532> importpubkey also doesn't cause bitcoind to pick up pure segwit payments... :-/
600 2016-07-20T18:50:08  <arubi> bsm117532, I wonder if it'd track it using createwitnessaddress
601 2016-07-20T18:51:19  <arubi> well probably not
602 2016-07-20T18:51:42  <bsm117532> I don't understand what createwitnessaddress is for...
603 2016-07-20T18:52:02  <arubi> oh disregard entirely, you want to track p2wpkh
604 2016-07-20T18:52:14  <arubi> it's for creating p2sh(p2wsh(..))
605 2016-07-20T18:52:21  <bsm117532> Oh I see
606 2016-07-20T18:55:03  <arubi> what about tracking using bip32?  that's what I'm doing now so suddenly I think it's good for everything :)
607 2016-07-20T18:56:06  <bsm117532> Well I know all the txids involved, the problem is that even with -txindex, bitcoind isn't indexing them, because they're not in my wallet!
608 2016-07-20T18:56:23  <arubi> oh sure it will index them with txindex
609 2016-07-20T18:56:32  <bsm117532> (so gettransaction doesn't work on these P2WPKH -> P2WPKH transactions)
610 2016-07-20T18:56:50  <bsm117532> txindex indexes everything, not only things in your wallet?
611 2016-07-20T18:56:54  <arubi> you should be using getrawtransaction <txid> 1 ( 1 if you want json)
612 2016-07-20T18:58:20  <arubi> gettransaction is handled by the wallet, for wallet txs
613 2016-07-20T18:58:43  <bsm117532> arubi saves my bacon, again
614 2016-07-20T18:59:01  <arubi> :)
615 2016-07-20T19:01:08  <bsm117532> https://www.youtube.com/watch?v=QSHaERIvFNE
616 2016-07-20T19:01:19  <bsm117532> "light bulb"
617 2016-07-20T19:02:39  *** supasonic has joined #bitcoin-core-dev
618 2016-07-20T19:15:15  <GitHub167> [bitcoin] instagibbs opened pull request #8384: Add witness data output to TxInError messages (master...txinerr) https://github.com/bitcoin/bitcoin/pull/8384
619 2016-07-20T19:28:33  *** fengling has joined #bitcoin-core-dev
620 2016-07-20T19:29:13  <bsm117532> I can test that instagibbs, shall I tACK it?  I'm new to the procedures...
621 2016-07-20T19:30:42  <Chris_Stewart_5> sipa: Does what we were talking about earlier apply to int's? I'm looking at how transactions are serialized for signatures and I see this line
622 2016-07-20T19:30:44  <Chris_Stewart_5> https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L1166
623 2016-07-20T19:30:55  <gmaxwell> bsm117532: if you've tested and it works you can tested ack.
624 2016-07-20T19:31:05  <bsm117532> will do
625 2016-07-20T19:31:20  <instagibbs> I just tested the bip143 examples, so please test :)
626 2016-07-20T19:31:26  <Chris_Stewart_5> If we have an 'int' that is 4 bytes it is serialized to 4 bytes, however if we have a number such as SIGHASH_ALL(1) it is serialized to '01'
627 2016-07-20T19:31:47  <Chris_Stewart_5> specifically this is related to some of the tests in sighash.json with really large hash types
628 2016-07-20T19:33:06  *** fengling has quit IRC
629 2016-07-20T19:35:13  *** netsin has quit IRC
630 2016-07-20T19:36:21  <Chris_Stewart_5> wait..
631 2016-07-20T19:37:11  <Chris_Stewart_5> nvm
632 2016-07-20T19:38:43  <bsm117532> Chris_Stewart_5: that's going to get serialized as a varint if nHashType is very large, isn't it?
633 2016-07-20T19:39:37  <Chris_Stewart_5> bsm117532: No, it is serialized as a 4 byte integer, I'm confusing myself with something else :-)
634 2016-07-20T19:42:24  <Chris_Stewart_5> bsm117532: I'm getting confused with actually checking the signature, which has to be an 'unsigned char' https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L1209
635 2016-07-20T19:42:38  * bsm117532 checks python-bitcoinlib -- which serializes as an *unsigned* int while bitcoind is using a *signed* int.  I hope that never matters, but I'd better fix it.
636 2016-07-20T19:49:49  *** jtimon has joined #bitcoin-core-dev
637 2016-07-20T19:49:53  <bsm117532> instagibbs: might as well add the empty-witness check to your PR.  https://github.com/instagibbs/bitcoin/blob/txinerr/src/script/interpreter.cpp#L1320
638 2016-07-20T19:50:11  <bsm117532> After that line adD: if (witness.stack.size() == 0) { return set_error(serror, SCRIPT_ERR_WITNESS_PROGRAM_WITNESS_EMPTY); }
639 2016-07-20T19:50:49  <instagibbs> I'm not going to mix debug and consensus PRs ;P
640 2016-07-20T19:51:59  <instagibbs> (even though it should be obviously correct)
641 2016-07-20T19:52:30  <jtimon> instagibbs: no, use CValidationState and the debugging can be done after the faulied check
642 2016-07-20T19:53:43  <jtimon> see https://github.com/bitcoin/bitcoin/pull/8341 for example
643 2016-07-20T19:54:09  <jtimon> well, I don't know what you were discussing before, so maybe I got you out of context...
644 2016-07-20T19:54:38  <jtimon> oh, debug and consensus *PRs*, never mind
645 2016-07-20T19:54:41  * jtimon hides
646 2016-07-20T19:56:49  <instagibbs> :P
647 2016-07-20T19:58:34  *** mkarrer has quit IRC
648 2016-07-20T19:58:43  <bsm117532> I see how it is, make *me* do a consensus PR :-P
649 2016-07-20T19:59:30  * instagibbs hides
650 2016-07-20T20:01:56  *** mkarrer has joined #bitcoin-core-dev
651 2016-07-20T20:02:38  <Chris_Stewart_5> So if we have a hash type not explicitly defined as a SIGHASH procedure, it is casted to an unsigned char then appended to the signature?
652 2016-07-20T20:02:39  *** mkarrer has joined #bitcoin-core-dev
653 2016-07-20T20:02:40  <Chris_Stewart_5> https://github.com/bitcoin/bitcoin/blob/d612837814020ae832499d18e6ee5eb919a87907/src/script/sign.cpp#L32
654 2016-07-20T20:04:34  *** Amnez777 has quit IRC
655 2016-07-20T20:05:37  <Chris_Stewart_5> and wherever the number ends up is the procedure that is used?
656 2016-07-20T20:06:11  *** cryptapus has quit IRC
657 2016-07-20T20:10:44  *** jannes has quit IRC
658 2016-07-20T20:11:40  *** Amnez777 has joined #bitcoin-core-dev
659 2016-07-20T20:29:32  *** fengling has joined #bitcoin-core-dev
660 2016-07-20T20:34:26  *** fengling has quit IRC
661 2016-07-20T20:36:00  *** netsin has joined #bitcoin-core-dev
662 2016-07-20T20:40:55  *** netsin has quit IRC
663 2016-07-20T20:43:00  *** netsin has joined #bitcoin-core-dev
664 2016-07-20T20:44:45  *** netsin has quit IRC
665 2016-07-20T20:47:43  <sipa> Chris_Stewart_5: hashtype is an integer, so it is serialized as 4 bytes
666 2016-07-20T20:51:34  *** frankenmint has quit IRC
667 2016-07-20T20:54:05  <sipa> Chris_Stewart_5: yes, the hash type is one byte, thought it's treated as a 32-bit int in the signature hash
668 2016-07-20T20:54:05  *** netsin has joined #bitcoin-core-dev
669 2016-07-20T20:56:37  *** laurentmt has joined #bitcoin-core-dev
670 2016-07-20T20:58:57  *** zooko has joined #bitcoin-core-dev
671 2016-07-20T20:59:51  *** laurentmt has quit IRC
672 2016-07-20T21:04:53  <sipa> when did segwit activate on testnet?
673 2016-07-20T21:06:25  <btcdrak> sipa: Dec 31st
674 2016-07-20T21:06:37  <btcdrak> oh wait i misread "segnet"
675 2016-07-20T21:07:05  <btcdrak> sipa: activation is listed here: https://github.com/bitcoin/bips/blob/master/bip-0009/assignments.mediawiki
676 2016-07-20T21:07:21  <btcdrak> #834624 on testnet
677 2016-07-20T21:11:05  <sipa> btcdrak: thanks
678 2016-07-20T21:11:11  <sipa> http://bitcoin.stackexchange.com/questions/46606/does-the-bitcoin-testnet3-network-support-segwit-and-op-csv
679 2016-07-20T21:11:39  <sipa> maybe we didn't really communicate clearly about that
680 2016-07-20T21:15:23  *** netsin has quit IRC
681 2016-07-20T21:21:42  *** Samdney has left #bitcoin-core-dev
682 2016-07-20T21:25:33  *** spudowiar has joined #bitcoin-core-dev
683 2016-07-20T21:31:05  *** fengling has joined #bitcoin-core-dev
684 2016-07-20T21:31:44  *** netsin has joined #bitcoin-core-dev
685 2016-07-20T21:34:34  *** netsin has quit IRC
686 2016-07-20T21:36:06  *** fengling has quit IRC
687 2016-07-20T21:40:29  <bsm117532> I'm puzzling over this transaction which appears as part of the tests in python-bitcoinlib: https://www.zerobin.net/?eb75da08cae8988f#I5FnTYeOK6+6lXtVfp9Wa0O+sZq/hNBhdXOE0zi0me0=
688 2016-07-20T21:41:18  <bsm117532> If I read it correctly, it's got zero inputs and one output, and those are identical to segwit's marker and flag bytes.
689 2016-07-20T21:42:00  <bsm117532> So, it should trigger segwit deserialization.  But bitcoin does not trigger segwit deserialization and I don't see why...
690 2016-07-20T21:42:46  *** belcher has joined #bitcoin-core-dev
691 2016-07-20T21:45:53  *** monkey_trauma has quit IRC
692 2016-07-20T21:55:57  <sipa> bsm117532: fundrawtransaction and decoderawtransaction first attempt to deserialize without witness support
693 2016-07-20T21:56:21  <sipa> as those are the only functions that can have a transaction with 0 inputs
694 2016-07-20T21:57:42  *** spudowiar has quit IRC
695 2016-07-20T21:57:55  *** zooko has quit IRC
696 2016-07-20T22:00:37  <bsm117532> Ah I see.
697 2016-07-20T22:01:33  <bsm117532> Thanks.  I think I'll change the test for this then.  It's an example of an invalid transaction, and is still invalid for segwit deserialization reasons instead of missing-input reasons.
698 2016-07-20T22:02:50  <bsm117532> It looks like this test was in Bitcoin around 0.9x and earlier but was removed.
699 2016-07-20T22:03:23  <sipa> if i had known about the need for deserializing transactions with 0 input i'd have made the flag byte 0xFF instead of 0x0
700 2016-07-20T22:03:43  <bsm117532> Has this been a problem for others?
701 2016-07-20T22:04:02  <sipa> longer term, there is no need why non-complete-transactions actually need to use the same serialization at all
702 2016-07-20T22:04:36  <sipa> and more complex multisig schemes will need a lot more metadata to be passed along betwee  signers, before a valid transaction appears
703 2016-07-20T22:04:41  <bsm117532> Good point...
704 2016-07-20T22:05:01  <sipa> so we can just come up with a better serialization format for that later
705 2016-07-20T22:05:09  <sipa> and get rid of that ambiguity that now exists
706 2016-07-20T22:05:23  *** btcfan has quit IRC
707 2016-07-20T22:13:08  *** Guyver2_ has joined #bitcoin-core-dev
708 2016-07-20T22:14:56  *** Guyver2 has quit IRC
709 2016-07-20T22:15:20  <bsm117532> I was just explaining to our intern why little endian exists.  Someday interns will ask why every financial system has these weird marker and flag bytes in its transactions.  ;-)
710 2016-07-20T22:15:59  <gmaxwell> don't let them get anywhere near biology.
711 2016-07-20T22:16:28  <GitHub51> [bitcoin] Hektve87 opened pull request #8385: Can't automatically merge (0.8...master) https://github.com/bitcoin/bitcoin/pull/8385
712 2016-07-20T22:19:20  *** Avinty_L_ has joined #bitcoin-core-dev
713 2016-07-20T22:20:19  *** whphhg_ has joined #bitcoin-core-dev
714 2016-07-20T22:20:29  *** Avinty_L_ has quit IRC
715 2016-07-20T22:21:20  <GitHub29> [bitcoin] Hektve87 closed pull request #8385: Can't automatically merge (0.8...master) https://github.com/bitcoin/bitcoin/pull/8385
716 2016-07-20T22:22:44  *** whphhg has quit IRC
717 2016-07-20T22:28:58  *** frankenmint has joined #bitcoin-core-dev
718 2016-07-20T22:29:30  *** zooko has joined #bitcoin-core-dev
719 2016-07-20T22:32:34  *** fengling has joined #bitcoin-core-dev
720 2016-07-20T22:34:49  *** mkarrer has quit IRC
721 2016-07-20T22:37:26  *** fengling has quit IRC
722 2016-07-20T22:42:23  *** mkarrer has joined #bitcoin-core-dev
723 2016-07-20T22:43:17  <jtimon> https://github.com/bitcoin/bitcoin/compare/master...jtimon:0.12.99-consensus-trivialish
724 2016-07-20T22:43:43  <jtimon> I have way too many PRs open, a link will be better
725 2016-07-20T22:44:54  <jtimon> includes 2 from nicolas dorian (#8342 #8341) and from me (#8348 #8347 #8346 ) and also also passes Consensus::Params instead of calling Params()
726 2016-07-20T22:45:01  <jtimon> should be easy to review
727 2016-07-20T23:30:03  *** alpalp has joined #bitcoin-core-dev
728 2016-07-20T23:30:03  *** alpalp has joined #bitcoin-core-dev
729 2016-07-20T23:31:49  *** zooko has quit IRC
730 2016-07-20T23:31:58  *** jiggalator has joined #bitcoin-core-dev
731 2016-07-20T23:33:43  *** whphhg_ is now known as whphhg
732 2016-07-20T23:34:04  *** fengling has joined #bitcoin-core-dev
733 2016-07-20T23:37:17  *** jiggalator has quit IRC
734 2016-07-20T23:39:06  *** fengling has quit IRC