1 2016-07-20 00:32:43	0|gmaxwell|luke-jr: so whats the deal with this sigops checking thing. Help me understand your position.
  2 2016-07-20 00:33:21	0|luke-jr|gmaxwell: does the comment I just posted help? or is there still confusion on it?
  3 2016-07-20 00:33:29	0|luke-jr|(literally seconds ago)
  4 2016-07-20 00:38:40	0|GitHub99|[13bitcoin] 15pstratem opened pull request #8376: Fix exception message to reference actual thrower. (06master...062016-07-19-cwallet-sethmasterkey) 02https://github.com/bitcoin/bitcoin/pull/8376
  5 2016-07-20 00:39:55	0|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.
  6 2016-07-20 00:40:04	0|gmaxwell|It shouldn't be done accidentally on the sly via another fix.
  7 2016-07-20 00:40:42	0|luke-jr|sure, I consider bare multisig policy entirely unrelated to these 2 PRs
  8 2016-07-20 00:40:57	0|CodeShark|what's bare multisig?
  9 2016-07-20 00:41:04	0|luke-jr|I think both PRs should be merged (once sipa's is updated to not remove the current bytespersigop)
 10 2016-07-20 00:41:10	0|luke-jr|CodeShark: multisig without p2sh
 11 2016-07-20 00:41:31	0|sipa|luke-jr: my PR does not remove -bytespersigop
 12 2016-07-20 00:41:40	0|luke-jr|CodeShark: accidentally broken in 0.12, fixed in #8364
 13 2016-07-20 00:41:55	0|luke-jr|sipa: it removes the current bytespersigop and adds a new one that does soemthing different.
 14 2016-07-20 00:42:00	0|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?
 15 2016-07-20 00:42:52	0|luke-jr|gmaxwell: for its original purpose: to filter spam misusing multisig
 16 2016-07-20 00:43:18	0|gmaxwell|well what kind of spam? people trying to store lots of data don't have a problem having more bytes.
 17 2016-07-20 00:44:13	0|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.
 18 2016-07-20 00:45:26	0|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(!) :/
 19 2016-07-20 00:45:51	0|luke-jr|nm, finally loaded: CVE-2013-2292
 20 2016-07-20 00:46:57	0|luke-jr|and apparently there's some kind of spam that dex guy wants to abuse it for as well
 21 2016-07-20 00:47:31	0|gmaxwell|yes, but the dex guy won't get hit by the current limit, he may be too ignorant to realize this.
 22 2016-07-20 00:47:37	0|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
 23 2016-07-20 00:48:12	0|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.
 24 2016-07-20 00:48:39	0|gmaxwell|luke-jr: in particular they pay as much (or likely more) fee than doing the attack with more ordinary looking transactions.
 25 2016-07-20 00:48:55	0|gmaxwell|So the abusive use really isn't help, abusers will adapt to do whatever works best for them.
 26 2016-07-20 00:49:29	0|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" ?
 27 2016-07-20 00:49:32	0|gmaxwell|and we are currently left with bare multisig users that, we know know, have problems reliably producing transactions under this policy.
 28 2016-07-20 00:49:56	0|luke-jr|gmaxwell: #8364 entirely fixes the current problem
 29 2016-07-20 00:50:10	0|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.
 30 2016-07-20 00:50:16	0|gmaxwell|E.g. we could release note that.
 31 2016-07-20 00:50:19	0|luke-jr|like we did with OP_RETURN?
 32 2016-07-20 00:50:23	0|luke-jr|we all know how that turned out..
 33 2016-07-20 00:50:46	0|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.
 34 2016-07-20 00:51:23	0|luke-jr|huh? #8364 would fix the bug so transacting parties are never affected
 35 2016-07-20 00:51:51	0|luke-jr|(sipa's change would probably do that, though)
 36 2016-07-20 00:52:34	0|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.
 37 2016-07-20 00:53:09	0|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.
 38 2016-07-20 00:53:20	0|luke-jr|what potential surprise consequences? it's a simple bugfix to existing released code, that only allows more transactions that were false-positives
 39 2016-07-20 00:53:52	0|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
 40 2016-07-20 00:54:15	0|luke-jr|miners might want to continue mining bare multisig after defaults change, yet not open this attack risk
 41 2016-07-20 00:54:30	0|sipa|we're really talking about different problems
 42 2016-07-20 00:54:57	0|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
 43 2016-07-20 00:54:57	0|sipa|you're concerned about sending an unintentional signal that high-sigop transactions are ok
 44 2016-07-20 00:55:07	0|sipa|i'm concerned about blocks being filled with garbage
 45 2016-07-20 00:55:31	0|gmaxwell|s/are okay/are okay if you pay some market fee/
 46 2016-07-20 00:55:54	0|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
 47 2016-07-20 00:56:30	0|sipa|however, we do now actually have a fee market
 48 2016-07-20 00:56:31	0|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.
 49 2016-07-20 00:56:33	0|luke-jr|sipa: if reality is they will, then reality is highly against Bitcoin surviving
 50 2016-07-20 00:56:34	0|CodeShark|sipa: I agree - we should not be deciding use cases, only working to ensure incentives don't get out of whack
 51 2016-07-20 00:57:14	0|sipa|luke-jr: and policy (and even consensus rules) can be proposed to combat certain behaviour that damages shared resources
 52 2016-07-20 00:57:18	0|luke-jr|miners are less likely to mine spam-padded-to-bypass-spam-limits than spam-just-paying-a-higher-fee IMO
 53 2016-07-20 00:57:25	0|luke-jr|intentionally*
 54 2016-07-20 00:57:57	0|gmaxwell|luke-jr: yea, slightly,-- which is the argument against ltc like 'dust' limits. But it's a minor detail at this point.
 55 2016-07-20 00:58:29	0|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
 56 2016-07-20 00:58:43	0|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.
 57 2016-07-20 00:58:46	0|sipa|that is a directly exploitable bug we'd be shipping in our mining code
 58 2016-07-20 00:59:07	0|sipa|and much more serious than a worry about a potentially misinterpreted signal _to people who are already using it anyway_
 59 2016-07-20 00:59:24	0|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)
 60 2016-07-20 00:59:30	0|gmaxwell|not just exploitable, previously actively exploited.
 61 2016-07-20 00:59:50	0|luke-jr|sipa: I'm arguing for *both*, not 8364 *instead of* yours
 62 2016-07-20 00:59:55	0|sipa|luke-jr: ok, fair enough
 63 2016-07-20 01:00:03	0|gmaxwell|luke-jr: the _current_ unmodified bytes per sigops blocks some bare multisig usage.
 64 2016-07-20 01:00:15	0|luke-jr|gmaxwell: accidentally
 65 2016-07-20 01:00:22	0|gmaxwell|Sure. It's a bug, we need to fix it.
 66 2016-07-20 01:00:34	0|luke-jr|so we fix that, and independently add sipa's policy.
 67 2016-07-20 01:00:51	0|sipa|luke-jr: both together are acceptable, but more complexity, and i'm not sure what it gains
 68 2016-07-20 01:00:58	0|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.
 69 2016-07-20 01:01:45	0|sipa|but you agree that 8364 (on its own) would be a bad idea?
 70 2016-07-20 01:02:24	0|luke-jr|sipa: I don't believe I have sufficient information to answer that.
 71 2016-07-20 01:02:51	0|luke-jr|or rather, I have to do some analysis of the information I have, that i have not yet done
 72 2016-07-20 01:04:34	0|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
 73 2016-07-20 01:04:37	0|gmaxwell|luke-jr: without 8365, 8364 would reintroduct the consensus-sigops block exhaustion attack that was being actively exploited.
 74 2016-07-20 01:05:00	0|sipa|wrt concern about resource usage, we should propose to make bare multisig nonstandard
 75 2016-07-20 01:07:17	0|gmaxwell|we should. But I think thats is seperate, perhaps just as a note in the release notes.
 76 2016-07-20 01:07:28	0|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
 77 2016-07-20 01:08:01	0|luke-jr|seems just doing 1-of-2 baremultisigs legitimately might actually be an economic concern in the same sense
 78 2016-07-20 01:10:04	0|gmaxwell|hah.
 79 2016-07-20 01:10:35	0|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. :)
 80 2016-07-20 01:11:08	0|luke-jr|mostly on https://github.com/bitcoin/bitcoin/issues/8079
 81 2016-07-20 01:11:26	0|luke-jr|IIRC
 82 2016-07-20 01:11:41	0|luke-jr|maybe it got lost in the other bs on that thread
 83 2016-07-20 01:11:54	0|sipa|i thought 8365 was the obvious fix all the time :)
 84 2016-07-20 01:12:07	0|luke-jr|bbiab
 85 2016-07-20 01:12:59	0|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)
 86 2016-07-20 01:13:46	0|gmaxwell|I missed 8079's discussion (because it got kind of hostile at some point).
 87 2016-07-20 02:44:17	0|GitHub106|[13bitcoin] 15pstratem opened pull request #8377: Rename usdhd option to createhdwallet (06master...062016-07-16-cwallet-createhdwallet) 02https://github.com/bitcoin/bitcoin/pull/8377
 88 2016-07-20 02:46:15	0|phantomcircuit|jonasschnelli, fyi qa/rpc-tests/wallet-hd.py passes even when i changed usehd to createhdwallet
 89 2016-07-20 02:46:30	0|phantomcircuit|which means it's broken maybe?
 90 2016-07-20 02:48:04	0|phantomcircuit|CHDChain & CKeyMetadata in walletdb.h seem like they could be in wallet.h instead
 91 2016-07-20 02:48:15	0|phantomcircuit|they're not really specific to the walletdb
 92 2016-07-20 02:48:37	0|phantomcircuit|otoh maybe it's reasonable that the abstraction be improved such that they are?
 93 2016-07-20 03:53:51	0|michagogo|Okay, PR created -- looks like it didn't happen automatically because GitHub moved their API endpoint, and my Octokit was outdated.
 94 2016-07-20 04:22:27	0|phantomcircuit|sipa: apparently returning a CKey doesn't work?
 95 2016-07-20 04:23:48	0|phantomcircuit|had to do this to 8375 https://gist.github.com/pstratem/a01c49e3be2a82076d240819e3823f31
 96 2016-07-20 05:32:39	0|GitHub9|[13bitcoin] 15pstratem opened pull request #8378: Move SetMinVersion for FEATURE_HD to SetHDMasterKey (06master...062016-07-19-cwallet-initloadwallet-ordering) 02https://github.com/bitcoin/bitcoin/pull/8378
 97 2016-07-20 07:10:51	0|GitHub21|13bitcoin/06master 143b3ce25 15Cory Fields: build: fix non-deterministic biplist...
 98 2016-07-20 07:10:51	0|GitHub21|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/045106b4f13c...c98abf2c7099
 99 2016-07-20 07:10:52	0|GitHub21|13bitcoin/06master 14c98abf2 15Wladimir J. van der Laan: Merge #8373: Fix OSX non-deterministic dmg...
100 2016-07-20 07:11:01	0|GitHub99|[13bitcoin] 15laanwj closed pull request #8373: Fix OSX non-deterministic dmg (06master...06biplist-determinism) 02https://github.com/bitcoin/bitcoin/pull/8373
101 2016-07-20 07:12:06	0|GitHub168|13bitcoin/060.13 141fe7f40 15Cory Fields: build: fix non-deterministic biplist...
102 2016-07-20 07:12:06	0|GitHub168|[13bitcoin] 15laanwj pushed 1 new commit to 060.13: 02https://github.com/bitcoin/bitcoin/commit/1fe7f404078121ad370ec955aa23befa322549bb
103 2016-07-20 07:15:49	0|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
104 2016-07-20 07:16:28	0|wumpus|I agree it should be solved obviously
105 2016-07-20 07:46:15	0|phantomcircuit|wumpus, updated the comment in #8378 think it needs to be tagged for 0.13
106 2016-07-20 07:50:21	0|wumpus|tagged
107 2016-07-20 07:58:03	0|Raccoon|8,8+--------------+   9,9+--------+   12,12+-----+   15,15+--------+   11,11+------+   13,13+------+   4,4+---+  
108 2016-07-20 07:58:04	0|Raccoon|  7,7################   3,3'--------    2,2\\\\\\\   14,14##########   10,10\\\\\\\\   6,6'------    5,5:::::
109 2016-07-20 07:58:04	0|Raccoon|8,8| 1,08#BITCOIN-DEV8,8 |7,7## 9,9| 1,09MISSES9,9 |3,3-  12,12| 0,12YOU12,12 |2,2\\ 15,15| 1,15GAVIN,15,15 |14,14## 11,11| 1,11COME11,11 |10,10\\ 13,13| 0,13HOME13,13 |6,6-  4,4| 0,04!4,4 |5,5::
110 2016-07-20 07:58:04	0|Raccoon|8,8+--------------+7,7## 9,9+--------+3,3 | 12,12+-----+2,2\\ 15,15+--------+14,14## 11,11+------+10,10\\ 13,13+------+6,6 | 4,4+---+5,5::
111 2016-07-20 07:59:06	0|luke-jr|!ops
112 2016-07-20 07:59:35	0|luke-jr|eh, he's not here? O.o
113 2016-07-20 08:00:18	0|phantomcircuit|luke-jr, lol it's a notice and the modes are set wrong
114 2016-07-20 08:00:33	0|luke-jr|phantomcircuit: modes are set "wrong" because that's how GitHub does commits :x
115 2016-07-20 08:00:51	0|phantomcircuit|luke-jr, lol
116 2016-07-20 08:01:05	0|phantomcircuit|i think you can still set a ban to keep him from doing it
117 2016-07-20 08:01:21	0|luke-jr|hm
118 2016-07-20 08:02:23	0|jl2012|the signed osx binary seems not deterministic?
119 2016-07-20 08:05:15	0|wumpus|jl2012: no, the ds_store is not deterministic
120 2016-07-20 08:05:24	0|wumpus|(which is not part of the signed data, but still affects the hash)
121 2016-07-20 08:05:51	0|btcdrak|phantomcircuit: no you can set github to come to the channel to post commit notices
122 2016-07-20 08:06:14	0|wumpus|see https://github.com/bitcoin/bitcoin/pull/8373
123 2016-07-20 08:09:21	0|jl2012|wumpus: so I should now rebuild for osx?
124 2016-07-20 08:09:38	0|wumpus|no, we'll just let this slide for rc1, for rc2 it will be solved
125 2016-07-20 08:10:07	0|jl2012|ok
126 2016-07-20 08:10:08	0|wumpus|(it's a change in the build system, not in the descriptor, so you can't easily build rc1 with that change)
127 2016-07-20 08:10:21	0|kinlo|hmmmz
128 2016-07-20 08:10:47	0|kinlo|this channel needs to be set +n (no messages from people not on the channel)
129 2016-07-20 08:11:00	0|kinlo|just make the github clients join the channel
130 2016-07-20 08:11:09	0|wumpus|then github can't paste into it
131 2016-07-20 08:11:15	0|btcdrak|wumpus: yes it can
132 2016-07-20 08:11:15	0|kinlo|github can join...
133 2016-07-20 08:11:19	0|btcdrak|it's a setting
134 2016-07-20 08:11:38	0|luke-jr|kinlo: way too spammy
135 2016-07-20 08:11:42	0|wumpus|I know, we had that in the beginning, but then github bots will be joining and parting all the time
136 2016-07-20 08:11:55	0|kinlo|luke-jr: and raccoon isn't ?:)
137 2016-07-20 08:12:04	0|luke-jr|Raccoon can be banned if he does it again
138 2016-07-20 08:12:11	0|luke-jr|he PM'd me he wouldn't
139 2016-07-20 08:12:20	0|wumpus|they distribute it over multiple bots, let's just ban the idiot and move on
140 2016-07-20 08:31:42	0|jonasschnelli|[23:45:16] <phantomcircuit:#bitcoin-core-dev> jonasschnelli, why does CHDKeyStore::PrivateKeyDerivation take the keypath as a string?
141 2016-07-20 08:31:59	0|jonasschnelli|phantomcircuit: I guess you are refering to one of my closed PR Bip32 PRs?
142 2016-07-20 08:32:20	0|jonasschnelli|I think somewhen we need a feature that can derive keys from a given string keypath.
143 2016-07-20 08:32:45	0|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
144 2016-07-20 08:33:02	0|jonasschnelli|phantomcircuit: usehd=1 is default....
145 2016-07-20 09:18:14	0|jl2012|wumpus: v0 witness program scriptPubKey becomes standard before activation even in mainnet. Do we need to mention this in release notes?
146 2016-07-20 09:18:53	0|jl2012|Now it says "Testnet-only segregated witness" but it affects some mainnet policy
147 2016-07-20 09:19:07	0|wumpus|jl2012: does it affect users in any way, in practice?
148 2016-07-20 09:19:56	0|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
149 2016-07-20 09:20:13	0|wumpus|it'll just confuse
150 2016-07-20 09:20:48	0|jl2012|only if someone generates bare segwit outputs. 0.13 will relay and mine these transactions
151 2016-07-20 09:21:40	0|wumpus|I don't understand, why is that the case for mainnet?
152 2016-07-20 09:22:17	0|sipa|spending them is non-standard, and won't be relayed before activation
153 2016-07-20 09:22:23	0|jl2012|because witness outputs are now starndard
154 2016-07-20 09:23:01	0|jl2012|I'm not talking about spending. I'm talking about sending to segwit outputs
155 2016-07-20 09:24:18	0|jl2012|precisely, if a scriptPubKey is OP_0 <20/32 bytes>, it becomes standard in 0.13
156 2016-07-20 09:25:35	0|gmaxwell|He means paying to a segwit output which doesn't use p2sh.
157 2016-07-20 09:25:44	0|jl2012|yes
158 2016-07-20 09:26:22	0|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)
159 2016-07-20 09:26:53	0|wumpus|so, all in all, it's still useless right now
160 2016-07-20 09:26:55	0|gmaxwell|I think perhaps we sould leave them non-standard in mainnet until there is an address encoding.
161 2016-07-20 09:27:15	0|gmaxwell|because it's useless and allowing useless things get dumb behavior enshrined.
162 2016-07-20 09:27:39	0|wumpus|yes - I guess they could be (mis)used for e.g. data storage?
163 2016-07-20 09:28:14	0|wumpus|like bare multisig
164 2016-07-20 09:29:04	0|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.
165 2016-07-20 09:29:55	0|jl2012|gmaxwell: I think even LN clients will use p2sh-segwit until there is a new address format?
166 2016-07-20 09:30:41	0|jl2012|technically speaking, people could use native segwit with BIP70
167 2016-07-20 09:30:56	0|sipa|right
168 2016-07-20 09:31:30	0|wumpus|I'm not sure standardness is meant as a way to prevent people from doing something stupid if they try very hard
169 2016-07-20 09:31:41	0|wumpus|I think just not mentioning this is enough to have no one care about it
170 2016-07-20 09:31:56	0|michagogo|There seems to be some unintentional markup going on here. https://usercontent.irccloud-cdn.com/file/1WImycPE/IMG_0002.PNG
171 2016-07-20 09:32:28	0|gmaxwell|jl2012: yea, but not on a network without any segwit support-- fair that I should back that until segwit is working.
172 2016-07-20 09:32:30	0|wumpus|michagogo: looks like a line starting with #
173 2016-07-20 09:32:52	0|michagogo|wumpus: yep, makes sense
174 2016-07-20 09:33:05	0|sipa|michagogo: yeah, the line need rewrapping
175 2016-07-20 09:33:16	0|michagogo|(That's the 0.13 release notes)
176 2016-07-20 09:33:21	0|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.
177 2016-07-20 09:34:52	0|sipa|should we do that even for segwit relay now?
178 2016-07-20 09:37:10	0|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.
179 2016-07-20 09:39:40	0|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.
180 2016-07-20 09:40:06	0|sipa|well it's a one-line change
181 2016-07-20 09:40:26	0|sipa|check bip9 status at tip.GetAncestor(144) instead of at tip
182 2016-07-20 09:40:39	0|sipa|if you want a day delay
183 2016-07-20 09:48:02	0|gmaxwell|well we're not even triggering relay of output creation on activation now.
184 2016-07-20 09:48:30	0|gmaxwell|(and we can't for p2sh, but I suppose there a potential attacker wouldn't usually know the preimage)
185 2016-07-20 09:48:57	0|GitHub102|[13bitcoin] 15jl2012 opened pull request #8379: Remove duplicated name in release notes (060.13...06patch-14) 02https://github.com/bitcoin/bitcoin/pull/8379
186 2016-07-20 09:51:25	0|GitHub109|[13bitcoin] 15laanwj closed pull request #8379: Remove duplicated name in release notes (060.13...06patch-14) 02https://github.com/bitcoin/bitcoin/pull/8379
187 2016-07-20 09:51:27	0|GitHub104|13bitcoin/060.13 1448b9208 15Johnson Lau: Remove duplicated name in release notes
188 2016-07-20 09:51:27	0|GitHub104|[13bitcoin] 15laanwj pushed 2 new commits to 060.13: 02https://github.com/bitcoin/bitcoin/compare/1fe7f4040781...f0ff08d7841c
189 2016-07-20 09:51:28	0|GitHub104|13bitcoin/060.13 14f0ff08d 15Wladimir J. van der Laan: Merge #8379: Remove duplicated name in release notes...
190 2016-07-20 09:57:55	0|GitHub113|13bitcoin/06master 146523fca 15Patrick Strateman: Move SetMinVersion for FEATURE_HD to SetHDMasterKey
191 2016-07-20 09:57:55	0|GitHub113|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/c98abf2c7099...8e048f40cc25
192 2016-07-20 09:57:56	0|GitHub113|13bitcoin/06master 148e048f4 15Wladimir J. van der Laan: Merge #8378: [Wallet]Move SetMinVersion for FEATURE_HD to SetHDMasterKey...
193 2016-07-20 09:58:05	0|GitHub114|[13bitcoin] 15laanwj closed pull request #8378: [Wallet]Move SetMinVersion for FEATURE_HD to SetHDMasterKey (06master...062016-07-19-cwallet-initloadwallet-ordering) 02https://github.com/bitcoin/bitcoin/pull/8378
194 2016-07-20 09:58:30	0|GitHub11|13bitcoin/060.13 14ebea651 15Patrick Strateman: Move SetMinVersion for FEATURE_HD to SetHDMasterKey...
195 2016-07-20 09:58:30	0|GitHub11|[13bitcoin] 15laanwj pushed 1 new commit to 060.13: 02https://github.com/bitcoin/bitcoin/commit/ebea65121e6c62f6b6acd79408a681b987126a0d
196 2016-07-20 10:07:12	0|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
197 2016-07-20 10:15:07	0|jannes|On topic of typos in release notes: "propagation relay" should be "propagation delay", I think.
198 2016-07-20 10:16:33	0|MarcoFalke|jannes: Pull request welcome :)
199 2016-07-20 10:17:57	0|sipa|jannes: indeed!
200 2016-07-20 10:25:50	0|jonasschnelli|btcdrak: nice! What block storage did you use? SDCard or USBStick? Did you had a corruption(s) during sync?
201 2016-07-20 10:28:07	0|btcdrak|jonasschnelli: I used a Samsung EVO+ 128MB, no corruption issues.
202 2016-07-20 10:28:52	0|jonasschnelli|btcdrak: Okay. I guess the bigger the SDCard space the less corruptions you will see (even if you don't use the space).
203 2016-07-20 10:28:56	0|jonasschnelli|Did you used prunining?
204 2016-07-20 10:29:14	0|btcdrak|jonasschnelli: No, no pruning. Full node.
205 2016-07-20 10:29:32	0|jonasschnelli|Technically with pruning its still a full node. :)
206 2016-07-20 10:29:41	0|jonasschnelli|Good to know.. I need to try the same on my Pine.
207 2016-07-20 10:29:47	0|btcdrak|jonasschnelli: It's a fuller node :-p
208 2016-07-20 10:29:53	0|jonasschnelli|;-)
209 2016-07-20 10:30:32	0|jonasschnelli|We should sell Pine64 together with a nice case and some webbase control center for 50$ as "your bank at home".
210 2016-07-20 10:33:20	0|GitHub70|[13bitcoin] 15jafaber opened pull request #8380: fix typo: propagation relay -> delay (060.13...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/8380
211 2016-07-20 10:35:26	0|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 :)
212 2016-07-20 10:39:54	0|sipa|jannes: looks good
213 2016-07-20 12:15:12	0|GitHub65|[13bitcoin] 15jl2012 opened pull request #8381: Make witness v0 outputs non-standard (06master...06patch-15) 02https://github.com/bitcoin/bitcoin/pull/8381
214 2016-07-20 13:03:13	0|GitHub128|[13bitcoin] 15jonasschnelli closed pull request #6481: [mining] allow other signal listeners to provide scripts for mining (06master...062015/07/enhance_mining_flexibility) 02https://github.com/bitcoin/bitcoin/pull/6481
215 2016-07-20 13:14:48	0|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
216 2016-07-20 13:15:05	0|Chris_Stewart_5|Can't an 'unsigned int' be larger than 4 bytes?
217 2016-07-20 13:15:44	0|sipa|Chris_Stewart_5: no, they're just integers
218 2016-07-20 13:16:01	0|sipa|Chris_Stewart_5: READWRITE(x) just invokes the serializer/deserializer for x
219 2016-07-20 13:16:25	0|sipa|vectors are serialized as compactsize(vector.size()), and then a concatenation of all the elements
220 2016-07-20 13:16:51	0|sipa|and no, the serialization code (so far) relies on unsigned int being 4 bytes
221 2016-07-20 13:20:53	0|Chris_Stewart_5|Hmm some how I got in my head that 'unsigned int' size isn't constant, looks like I was wrong
222 2016-07-20 13:21:45	0|sipa|the C standard does not fix its size
223 2016-07-20 13:22:00	0|sipa|but we don't support any architectures where it isn't 4 bytes
224 2016-07-20 13:22:48	0|Chris_Stewart_5|oh ok, thanks for the clarification
225 2016-07-20 16:37:18	0|GitHub104|[13bitcoin] 15dooglus opened pull request #8382: Fix formatting error (060.13...06patch-4) 02https://github.com/bitcoin/bitcoin/pull/8382
226 2016-07-20 16:50:11	0|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".
227 2016-07-20 16:52:57	0|sipa|bsm117532: is the witness script known?
228 2016-07-20 16:53:11	0|sipa|ah, or it's p2wpkh
229 2016-07-20 16:58:54	0|bsm117532|It's p2wpkh
230 2016-07-20 17:00:10	0|bsm117532|I bet I'm the only person using *raw* rpc calls with witness txns ;-)
231 2016-07-20 17:00:27	0|instagibbs|bsm117532, that error should only pop up if it fails VerifyScript?
232 2016-07-20 17:03:17	0|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?
233 2016-07-20 17:03:34	0|bsm117532|I'd think this wouldn't be a failure but should spit out the same transaction with "complete": false
234 2016-07-20 17:03:38	0|instagibbs|looks like the error for p2wpkh is just checking if the stack is size 2?
235 2016-07-20 17:03:44	0|instagibbs|if the hash it seems is size 20
236 2016-07-20 17:03:48	0|instagibbs|sees*
237 2016-07-20 17:04:20	0|instagibbs|https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L1323
238 2016-07-20 17:04:31	0|instagibbs|and a few lines before it, for the 32 byte case
239 2016-07-20 17:06:50	0|bsm117532|instagibbs: Yes, that's it. The witness stack size would be zero (because it's unsigned).
240 2016-07-20 17:07:13	0|instagibbs|ok so it pushes nothing, and fails later
241 2016-07-20 17:10:30	0|instagibbs|we should just be checking the return value of ProduceSignature, right?
242 2016-07-20 17:10:41	0|bsm117532|SCRIPT_ERR_WITNESS_PROGRAM_WITNESS_EMPTY is a better error if stack is empty
243 2016-07-20 17:12:49	0|instagibbs|it's a special case for p2wpkh
244 2016-07-20 17:12:55	0|instagibbs|not a great error message I agree though
245 2016-07-20 17:14:31	0|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!
246 2016-07-20 17:14:42	0|bsm117532|(My example only has one input)
247 2016-07-20 17:15:45	0|bsm117532|What happens with non-segwit p2pkh's here?  Won't they fail too?
248 2016-07-20 17:16:06	0|instagibbs|hmm? why would it fail with multiple valid inputs?
249 2016-07-20 17:16:19	0|bsm117532|Because it signs them one at a time.
250 2016-07-20 17:16:24	0|instagibbs|they will fail as well, the error here i think is just not helpful
251 2016-07-20 17:16:27	0|bsm117532|And calls verifyscript after each one
252 2016-07-20 17:16:34	0|instagibbs|that's how signing works
253 2016-07-20 17:17:14	0|bsm117532|So if I read this correctly, signrawtransaction would be incapable of signing something with multiple unsigned inputs?
254 2016-07-20 17:17:30	0|instagibbs|No, it signs anything it can
255 2016-07-20 17:18:20	0|instagibbs|then checks that script to see if it's satisfied
256 2016-07-20 17:18:35	0|instagibbs|in our case it's not, but it needs to spit out a better error
257 2016-07-20 17:18:44	0|bsm117532|The VerifyScript is inside the loop though...
258 2016-07-20 17:18:52	0|bsm117532|It should be outside.
259 2016-07-20 17:19:42	0|instagibbs|No, each input scriptSig needs to be checked individually
260 2016-07-20 17:20:04	0|bsm117532|Oh I see, `i` is passed.
261 2016-07-20 17:22:33	0|bsm117532|Does anyone have a good WIP to incorporate that change?  I can fix it with my segwit wallet improvements if not.
262 2016-07-20 17:30:58	0|instagibbs|bsm117532, it is true that the 32 byte version has an error already for empty witness
263 2016-07-20 17:32:25	0|instagibbs|seems useful as a debugging message for both
264 2016-07-20 17:32:38	0|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.
265 2016-07-20 17:34:44	0|sipa|sure, the result of signrawtransaction can be complete:false ?
266 2016-07-20 17:35:02	0|sipa|for example in case of multisig and you only have some of the keys
267 2016-07-20 17:35:39	0|bsm117532|I agree that's logically what it *should* do, but that VerifyScript called for each input fails if it's unsigned.
268 2016-07-20 17:35:45	0|bsm117532|I could be reading it wrong though...
269 2016-07-20 17:36:51	0|sipa|where did you see this error, btw?
270 2016-07-20 17:37:14	0|bsm117532|Running: bitcoin-cli signrawtransaction
271 2016-07-20 17:37:36	0|bsm117532|for a key that isn't in my wallet.  It's a simple one input, one output txn, both p2wpkh
272 2016-07-20 17:37:39	0|sipa|hmm, that should never return an error
273 2016-07-20 17:37:45	0|sipa|it should just not sign
274 2016-07-20 17:41:37	0|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.
275 2016-07-20 17:42:26	0|bsm117532|Could we remove SCRIPT_VERIFY_WITNESS from this call? https://github.com/bitcoin/bitcoin/blob/master/src/rpc/rawtransaction.cpp#L821
276 2016-07-20 17:44:05	0|sipa|i don't understand why we call that in the first place
277 2016-07-20 17:44:21	0|sipa|the only correctness check should be at the end, to determine the value of complete
278 2016-07-20 17:44:36	0|bsm117532|sipa: I agree
279 2016-07-20 17:44:37	0|instagibbs|"value of complete"?
280 2016-07-20 17:44:55	0|bsm117532|instagibbs pointed out that it's a per-input check...
281 2016-07-20 17:46:21	0|instagibbs|bsm117532, did you get back a partially signed txn?
282 2016-07-20 17:46:43	0|bsm117532|instagibbs: no, it fails.  I'll pastebin it for  you
283 2016-07-20 17:46:49	0|instagibbs|please do thanks
284 2016-07-20 17:47:23	0|bsm117532|https://www.zerobin.net/?c6f94fa664089370#rWaua+D/pcl0zvYh8DNwbjfh+XitXfJSNHEOHLscb+A=
285 2016-07-20 17:47:34	0|instagibbs|"hex"
286 2016-07-20 17:47:37	0|instagibbs|that's the partially signed
287 2016-07-20 17:48:07	0|bsm117532|Well it's not signed -- only one input.
288 2016-07-20 17:48:11	0|instagibbs|errr, yes
289 2016-07-20 17:48:20	0|instagibbs|but that's expected behavior if you don't have the key
290 2016-07-20 17:48:26	0|instagibbs|(potentially partially signed)
291 2016-07-20 17:49:05	0|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.
292 2016-07-20 17:49:12	0|instagibbs|kk, agreed
293 2016-07-20 17:49:42	0|bsm117532|Now how to get it to say "I don't have the keys..."  ;-)
294 2016-07-20 17:50:17	0|instagibbs|I think just add the 0 size check like the p2wsh has.
295 2016-07-20 17:50:42	0|bsm117532|Yes, I did that.  Will include it in my wallet updates.  Thanks!
296 2016-07-20 17:50:47	0|instagibbs|schweet
297 2016-07-20 17:51:15	0|instagibbs|do we want to augment TxInErrorToJSON to include witness data as hex?
298 2016-07-20 17:52:02	0|instagibbs|for a p2w{pkh/sh} we'll be given a blank scriptSig and nothing else
299 2016-07-20 17:52:12	0|bsm117532|Maybe...the error message is still unclear as to why it failed.
300 2016-07-20 17:52:42	0|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...
301 2016-07-20 18:04:32	0|arubi|bsm117532, which address?  the hash160(pubkey)?
302 2016-07-20 18:05:13	0|bsm117532|Yes.  It's a simple change to ExtractDestination.
303 2016-07-20 18:05:27	0|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.
304 2016-07-20 18:05:32	0|arubi|ah yea ^
305 2016-07-20 18:05:32	0|bsm117532|I don't think we can know the destination for P2WPKH though since it uses a 32 bit hash...
306 2016-07-20 18:05:54	0|bsm117532|arubi: That's exactly what I just did, compiling now... ;-)
307 2016-07-20 18:06:28	0|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
308 2016-07-20 18:06:41	0|bsm117532|Why not?
309 2016-07-20 18:07:15	0|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
310 2016-07-20 18:07:56	0|arubi|or, maybe it does have its uses
311 2016-07-20 18:08:43	0|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..
312 2016-07-20 18:08:45	0|bsm117532|I don't understand...the address in the scriptPubKey is the actual destination, and is consensus enforced, no?
313 2016-07-20 18:09:08	0|arubi|I don't understand the question, sorry
314 2016-07-20 18:09:52	0|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?
315 2016-07-20 18:09:59	0|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?
316 2016-07-20 18:10:19	0|arubi|there is no actual address for a witness v0 script, at least afaik
317 2016-07-20 18:11:05	0|bsm117532|Sure there is, it's that one in the scriptPubKey...unless I'm horribly confused.
318 2016-07-20 18:11:35	0|arubi|you mean 0x00 0x14 0x<hash160> ?
319 2016-07-20 18:11:41	0|bsm117532|Yes
320 2016-07-20 18:12:01	0|arubi|that has no address pattern that I know of, I might be wrong
321 2016-07-20 18:12:38	0|bsm117532|My tiny patch does this: https://www.zerobin.net/?ad6eb3578c41e566#Sy4WYHvXEqVGSD3+raknP1SfNUzN+KC9AsejLzSIReI=
322 2016-07-20 18:12:49	0|arubi|right, that's what I did.
323 2016-07-20 18:13:09	0|bsm117532|What's wrong with this address msFV...?
324 2016-07-20 18:13:18	0|arubi|it's a p2pkh script address
325 2016-07-20 18:13:59	0|bsm117532|So?  it's the corresponding input that determines that a segregated witness needs to be used, not the address itself.
326 2016-07-20 18:14:00	0|arubi|it might help with referencing the private key, because that's how core works, but nothing else
327 2016-07-20 18:15:04	0|arubi|I agree that it has some value to a power user, but it's confusing at best to anyone else
328 2016-07-20 18:15:35	0|bsm117532|How could it possibly be confusing?  Is there any chance that the privkey corresponding to msFV... does not control the sent funds?
329 2016-07-20 18:16:07	0|bsm117532|This scriptPubKey is the only indicator of the destination address...
330 2016-07-20 18:16:15	0|arubi|it's not about that, listing that address will make folks accidentally accept payments to both v0 witnesses /and/ that p2pkh script
331 2016-07-20 18:17:27	0|bsm117532|The new address types BIP for segwit was deferred.  I don't fully understand that...
332 2016-07-20 18:17:42	0|arubi|there is no address type for v0 and v0 witnesses
333 2016-07-20 18:17:56	0|arubi|er, v0/v1
334 2016-07-20 18:17:56	0|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?
335 2016-07-20 18:18:27	0|arubi|no one is going to accept payments to segwit scripts unless they actually know what they're doing, at least at first
336 2016-07-20 18:19:01	0|bsm117532|Sure
337 2016-07-20 18:19:10	0|arubi|bsm117532, the correct way now is to wrap it in a p2sh
338 2016-07-20 18:19:46	0|bsm117532|Well without this decoding step, `decoderawtransaction` gives absolutely no indication of the destination...which is why I want to decode it.  :-P
339 2016-07-20 18:19:51	0|instagibbs|bsm117532, im working on a small PR to print out witness data when errors occur in signing
340 2016-07-20 18:20:12	0|bsm117532|arubi: FWIW I'm building an application that will be segwit-only.
341 2016-07-20 18:20:20	0|bsm117532|instagibbs: cool
342 2016-07-20 18:20:35	0|arubi|bsm117532, what do you need a 1... address for then? :)
343 2016-07-20 18:21:23	0|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?
344 2016-07-20 18:21:35	0|arubi|no no
345 2016-07-20 18:21:53	0|arubi|a p2wpkh has no address type.  when it gets one, /that/ should be listed in "addresses"
346 2016-07-20 18:23:18	0|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
347 2016-07-20 18:23:24	0|bsm117532|So I've been sending funds to P2PKH (hash160) addresses, with segregated witness, and it works fine!
348 2016-07-20 18:23:42	0|bsm117532|Oh I see what you're saying
349 2016-07-20 18:24:09	0|arubi|well a v0 witness has a scriptcode just like a p2pkh script, so it verifies the same
350 2016-07-20 18:24:32	0|bsm117532|arubi: No, a 1...address is a version byte concatenated with the hash160...
351 2016-07-20 18:24:47	0|bsm117532|and the segregated witness verifies the hash160.
352 2016-07-20 18:24:48	0|arubi|that's just the encoding, not the actual payment script
353 2016-07-20 18:25:09	0|bsm117532|Sure
354 2016-07-20 18:25:13	0|arubi|no, it actually does a p2pkh verification.  hash(pubkey) == hash && scriptsig & pubkey
355 2016-07-20 18:25:20	0|bsm117532|Yes
356 2016-07-20 18:25:28	0|bsm117532|Yes the script is implicit.
357 2016-07-20 18:25:40	0|arubi|but not the address encoding
358 2016-07-20 18:26:02	0|arubi|the 1.. address encoding is not the correct output.  an eventual v0 script address is
359 2016-07-20 18:26:18	0|arubi|v0 witness*
360 2016-07-20 18:27:16	0|bsm117532|So there is an intent to bring BIP 142 and new address types (eventually) then?
361 2016-07-20 18:27:42	0|arubi|I don't know.  I hope there will be, so people could use it
362 2016-07-20 18:28:01	0|arubi|p2wsh(p2pk) is what you want now for about the same functionality
363 2016-07-20 18:28:05	0|bsm117532|To be clear, I can create and spend P2WPKH funds on testnet, now.
364 2016-07-20 18:28:11	0|instagibbs|bsm117532, sipa has been working on better address schemes. Not sure when he'll be "done" though :)
365 2016-07-20 18:28:17	0|bsm117532|I see
366 2016-07-20 18:28:48	0|arubi|yes, spend to bare sigs and redeem them, it's all possible. but a simple wallet couldn't send /to/ you
367 2016-07-20 18:28:55	0|arubi|bare scripts*
368 2016-07-20 18:30:15	0|bsm117532|FYI, `decoderawtransaction` DOES decode V0 witness addresses as I wanted to do above.
369 2016-07-20 18:31:49	0|arubi|now after the patch, or before? :)
370 2016-07-20 18:32:09	0|bsm117532|now
371 2016-07-20 18:32:15	0|bsm117532|Oh....
372 2016-07-20 18:32:45	0|arubi|it's amazing how we've now both walked the same path :P
373 2016-07-20 18:33:00	0|bsm117532|Hahaa you're right my patch changed that output.
374 2016-07-20 18:35:43	0|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)
375 2016-07-20 18:36:51	0|arubi|cheers bsm117532
376 2016-07-20 18:38:40	0|bsm117532|I guess what I need to do is to get bitcoind to add a single txn to its txindex.  (Or use P2SH embedding)
377 2016-07-20 18:40:05	0|GitHub69|13bitcoin/060.13 14ea91961 15Chris Moore: Fix formatting error...
378 2016-07-20 18:40:05	0|GitHub69|[13bitcoin] 15jonasschnelli pushed 2 new commits to 060.13: 02https://github.com/bitcoin/bitcoin/compare/ebea65121e6c...66dde4edf733
379 2016-07-20 18:40:06	0|GitHub69|13bitcoin/060.13 1466dde4e 15Jonas Schnelli: Merge #8382: Fix formatting error...
380 2016-07-20 18:40:07	0|GitHub22|[13bitcoin] 15jonasschnelli closed pull request #8382: Fix formatting error (060.13...06patch-4) 02https://github.com/bitcoin/bitcoin/pull/8382
381 2016-07-20 18:42:46	0|arubi|why not p2sh(p2wsh({p2pk,multisig})) ? much more versatile
382 2016-07-20 18:44:29	0|bsm117532|I'm trying to be efficient and this is a non-wallet usage. ;-)
383 2016-07-20 18:44:37	0|bsm117532|Also, learn segwit by fire...
384 2016-07-20 18:46:14	0|bsm117532|importpubkey also doesn't cause bitcoind to pick up pure segwit payments... :-/
385 2016-07-20 18:50:08	0|arubi|bsm117532, I wonder if it'd track it using createwitnessaddress
386 2016-07-20 18:51:19	0|arubi|well probably not
387 2016-07-20 18:51:43	0|bsm117532|I don't understand what createwitnessaddress is for...
388 2016-07-20 18:52:03	0|arubi|oh disregard entirely, you want to track p2wpkh
389 2016-07-20 18:52:11	0|arubi|it's for creating p2sh(p2wsh(..))
390 2016-07-20 18:52:21	0|bsm117532|Oh I see
391 2016-07-20 18:55:04	0|arubi|what about tracking using bip32?  that's what I'm doing now so suddenly I think it's good for everything :)
392 2016-07-20 18:56:07	0|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!
393 2016-07-20 18:56:24	0|arubi|oh sure it will index them with txindex
394 2016-07-20 18:56:33	0|bsm117532|(so gettransaction doesn't work on these P2WPKH -> P2WPKH transactions)
395 2016-07-20 18:56:50	0|bsm117532|txindex indexes everything, not only things in your wallet?
396 2016-07-20 18:56:54	0|arubi|you should be using getrawtransaction <txid> 1 ( 1 if you want json)
397 2016-07-20 18:57:12	0|arubi|gettransaction is handled by the wallet, for wallet txs
398 2016-07-20 18:58:44	0|bsm117532|arubi saves my bacon, again
399 2016-07-20 18:59:01	0|arubi|:)
400 2016-07-20 19:01:08	0|bsm117532|https://www.youtube.com/watch?v=QSHaERIvFNE
401 2016-07-20 19:01:14	0|bsm117532|"light bulb"
402 2016-07-20 19:15:15	0|GitHub167|[13bitcoin] 15instagibbs opened pull request #8384: Add witness data output to TxInError messages (06master...06txinerr) 02https://github.com/bitcoin/bitcoin/pull/8384
403 2016-07-20 19:29:14	0|bsm117532|I can test that instagibbs, shall I tACK it?  I'm new to the procedures...
404 2016-07-20 19:30:43	0|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
405 2016-07-20 19:30:45	0|Chris_Stewart_5|https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L1166
406 2016-07-20 19:30:55	0|gmaxwell|bsm117532: if you've tested and it works you can tested ack.
407 2016-07-20 19:31:05	0|bsm117532|will do
408 2016-07-20 19:31:20	0|instagibbs|I just tested the bip143 examples, so please test :)
409 2016-07-20 19:31:26	0|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'
410 2016-07-20 19:31:48	0|Chris_Stewart_5|specifically this is related to some of the tests in sighash.json with really large hash types
411 2016-07-20 19:36:21	0|Chris_Stewart_5|wait..
412 2016-07-20 19:37:11	0|Chris_Stewart_5|nvm
413 2016-07-20 19:38:44	0|bsm117532|Chris_Stewart_5: that's going to get serialized as a varint if nHashType is very large, isn't it?
414 2016-07-20 19:39:37	0|Chris_Stewart_5|bsm117532: No, it is serialized as a 4 byte integer, I'm confusing myself with something else :-)
415 2016-07-20 19:42:25	0|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
416 2016-07-20 19:49:54	0|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
417 2016-07-20 19:50:12	0|bsm117532|After that line adD: if (witness.stack.size() == 0) { return set_error(serror, SCRIPT_ERR_WITNESS_PROGRAM_WITNESS_EMPTY); }
418 2016-07-20 19:50:50	0|instagibbs|I'm not going to mix debug and consensus PRs ;P
419 2016-07-20 19:52:00	0|instagibbs|(even though it should be obviously correct)
420 2016-07-20 19:52:30	0|jtimon|instagibbs: no, use CValidationState and the debugging can be done after the faulied check
421 2016-07-20 19:53:43	0|jtimon|see https://github.com/bitcoin/bitcoin/pull/8341 for example
422 2016-07-20 19:54:09	0|jtimon|well, I don't know what you were discussing before, so maybe I got you out of context...
423 2016-07-20 19:54:38	0|jtimon|oh, debug and consensus *PRs*, never mind
424 2016-07-20 19:56:49	0|instagibbs|:P
425 2016-07-20 19:58:43	0|bsm117532|I see how it is, make *me* do a consensus PR :-P
426 2016-07-20 20:02:38	0|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?
427 2016-07-20 20:02:41	0|Chris_Stewart_5|https://github.com/bitcoin/bitcoin/blob/d612837814020ae832499d18e6ee5eb919a87907/src/script/sign.cpp#L32
428 2016-07-20 20:05:37	0|Chris_Stewart_5|and wherever the number ends up is the procedure that is used?
429 2016-07-20 20:47:44	0|sipa|Chris_Stewart_5: hashtype is an integer, so it is serialized as 4 bytes
430 2016-07-20 20:54:05	0|sipa|Chris_Stewart_5: yes, the hash type is one byte, thought it's treated as a 32-bit int in the signature hash
431 2016-07-20 21:04:54	0|sipa|when did segwit activate on testnet?
432 2016-07-20 21:06:26	0|btcdrak|sipa: Dec 31st
433 2016-07-20 21:06:38	0|btcdrak|oh wait i misread "segnet"
434 2016-07-20 21:07:06	0|btcdrak|sipa: activation is listed here: https://github.com/bitcoin/bips/blob/master/bip-0009/assignments.mediawiki
435 2016-07-20 21:07:21	0|btcdrak|#834624 on testnet
436 2016-07-20 21:11:06	0|sipa|btcdrak: thanks
437 2016-07-20 21:11:11	0|sipa|http://bitcoin.stackexchange.com/questions/46606/does-the-bitcoin-testnet3-network-support-segwit-and-op-csv
438 2016-07-20 21:11:40	0|sipa|maybe we didn't really communicate clearly about that
439 2016-07-20 21:40:30	0|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=
440 2016-07-20 21:41:19	0|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.
441 2016-07-20 21:42:01	0|bsm117532|So, it should trigger segwit deserialization.  But bitcoin does not trigger segwit deserialization and I don't see why...
442 2016-07-20 21:55:58	0|sipa|bsm117532: fundrawtransaction and decoderawtransaction first attempt to deserialize without witness support
443 2016-07-20 21:56:22	0|sipa|as those are the only functions that can have a transaction with 0 inputs
444 2016-07-20 22:00:38	0|bsm117532|Ah I see.
445 2016-07-20 22:01:34	0|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.
446 2016-07-20 22:02:51	0|bsm117532|It looks like this test was in Bitcoin around 0.9x and earlier but was removed.
447 2016-07-20 22:03:24	0|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
448 2016-07-20 22:03:44	0|bsm117532|Has this been a problem for others?
449 2016-07-20 22:04:02	0|sipa|longer term, there is no need why non-complete-transactions actually need to use the same serialization at all
450 2016-07-20 22:04:36	0|sipa|and more complex multisig schemes will need a lot more metadata to be passed along betwee  signers, before a valid transaction appears
451 2016-07-20 22:04:41	0|bsm117532|Good point...
452 2016-07-20 22:05:02	0|sipa|so we can just come up with a better serialization format for that later
453 2016-07-20 22:05:10	0|sipa|and get rid of that ambiguity that now exists
454 2016-07-20 22:15:21	0|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.  ;-)
455 2016-07-20 22:15:59	0|gmaxwell|don't let them get anywhere near biology.
456 2016-07-20 22:16:28	0|GitHub51|[13bitcoin] 15Hektve87 opened pull request #8385: Can't automatically merge (060.8...06master) 02https://github.com/bitcoin/bitcoin/pull/8385
457 2016-07-20 22:21:20	0|GitHub29|[13bitcoin] 15Hektve87 closed pull request #8385: Can't automatically merge (060.8...06master) 02https://github.com/bitcoin/bitcoin/pull/8385
458 2016-07-20 22:43:17	0|jtimon|https://github.com/bitcoin/bitcoin/compare/master...jtimon:0.12.99-consensus-trivialish
459 2016-07-20 22:43:43	0|jtimon|I have way too many PRs open, a link will be better
460 2016-07-20 22:44:54	0|jtimon|includes 2 from nicolas dorian (#8342 #8341) and from me (#8348 #8347 #8346 ) and also also passes Consensus::Params instead of calling Params()
461 2016-07-20 22:45:01	0|jtimon|should be easy to review