12016-07-20T00:02:29  *** Giszmo has joined #bitcoin-core-dev
  22016-07-20T00:08:28  *** PRab has joined #bitcoin-core-dev
  32016-07-20T00:16:13  *** PRab has quit IRC
  42016-07-20T00:17:30  *** NicLin has joined #bitcoin-core-dev
  52016-07-20T00:25:48  *** Ylbam has quit IRC
  62016-07-20T00:32:43  <gmaxwell> luke-jr: so whats the deal with this sigops checking thing. Help me understand your position.
  72016-07-20T00:33:21  <luke-jr> gmaxwell: does the comment I just posted help? or is there still confusion on it?
  82016-07-20T00:33:29  <luke-jr> (literally seconds ago)
  92016-07-20T00:34:00  * gmaxwell goes to read
 102016-07-20T00:35:46  *** fengling has quit IRC
 112016-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
 122016-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.
 132016-07-20T00:40:04  <gmaxwell> It shouldn't be done accidentally on the sly via another fix.
 142016-07-20T00:40:42  <luke-jr> sure, I consider bare multisig policy entirely unrelated to these 2 PRs
 152016-07-20T00:40:57  <CodeShark> what's bare multisig?
 162016-07-20T00:41:04  <luke-jr> I think both PRs should be merged (once sipa's is updated to not remove the current bytespersigop)
 172016-07-20T00:41:10  <luke-jr> CodeShark: multisig without p2sh
 182016-07-20T00:41:30  <sipa> luke-jr: my PR does not remove -bytespersigop
 192016-07-20T00:41:40  <luke-jr> CodeShark: accidentally broken in 0.12, fixed in #8364
 202016-07-20T00:41:55  <luke-jr> sipa: it removes the current bytespersigop and adds a new one that does soemthing different.
 212016-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?
 222016-07-20T00:42:51  <luke-jr> gmaxwell: for its original purpose: to filter spam misusing multisig
 232016-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.
 242016-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.
 252016-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(!) :/
 262016-07-20T00:45:51  <luke-jr> nm, finally loaded: CVE-2013-2292
 272016-07-20T00:46:57  <luke-jr> and apparently there's some kind of spam that dex guy wants to abuse it for as well
 282016-07-20T00:47:13  *** fengling has joined #bitcoin-core-dev
 292016-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.
 302016-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
 312016-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.
 322016-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.
 332016-07-20T00:48:54  *** netsin has quit IRC
 342016-07-20T00:48:55  <gmaxwell> So the abusive use really isn't help, abusers will adapt to do whatever works best for them.
 352016-07-20T00:49:15  *** alpalp has joined #bitcoin-core-dev
 362016-07-20T00:49:16  *** alpalp has joined #bitcoin-core-dev
 372016-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" ?
 382016-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.
 392016-07-20T00:49:33  *** netsin has joined #bitcoin-core-dev
 402016-07-20T00:49:56  <luke-jr> gmaxwell: #8364 entirely fixes the current problem
 412016-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.
 422016-07-20T00:50:16  <gmaxwell> E.g. we could release note that.
 432016-07-20T00:50:19  <luke-jr> like we did with OP_RETURN?
 442016-07-20T00:50:23  <luke-jr> we all know how that turned out..
 452016-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.
 462016-07-20T00:51:23  <luke-jr> huh? #8364 would fix the bug so transacting parties are never affected
 472016-07-20T00:51:51  <luke-jr> (sipa's change would probably do that, though)
 482016-07-20T00:52:07  *** justanotheruser has quit IRC
 492016-07-20T00:52:15  *** justanot1eruser has joined #bitcoin-core-dev
 502016-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.
 512016-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.
 522016-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
 532016-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
 542016-07-20T00:54:03  *** netsin has quit IRC
 552016-07-20T00:54:15  <luke-jr> miners might want to continue mining bare multisig after defaults change, yet not open this attack risk
 562016-07-20T00:54:29  <sipa> we're really talking about different problems
 572016-07-20T00:54:53  *** justanot1eruser is now known as justanotheruser
 582016-07-20T00:54:56  <sipa> you're concerned about sending an unintentional signal that high-sigop transactions are ok
 592016-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
 602016-07-20T00:55:06  <sipa> i'm concerned about blocks being filled with garbage
 612016-07-20T00:55:30  <gmaxwell> s/are okay/are okay if you pay some market fee/
 622016-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
 632016-07-20T00:56:15  *** netsin has joined #bitcoin-core-dev
 642016-07-20T00:56:29  <sipa> however, we do now actually have a fee market
 652016-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.
 662016-07-20T00:56:33  <luke-jr> sipa: if reality is they will, then reality is highly against Bitcoin surviving
 672016-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
 682016-07-20T00:57:13  <sipa> luke-jr: and policy (and even consensus rules) can be proposed to combat certain behaviour that damages shared resources
 692016-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
 702016-07-20T00:57:25  <luke-jr> intentionally*
 712016-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.
 722016-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
 732016-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.
 742016-07-20T00:58:46  <sipa> that is a directly exploitable bug we'd be shipping in our mining code
 752016-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_
 762016-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)
 772016-07-20T00:59:35  <gmaxwell> not just exploitable, previously actively exploited.
 782016-07-20T00:59:49  <luke-jr> sipa: I'm arguing for *both*, not 8364 *instead of* yours
 792016-07-20T00:59:55  <sipa> luke-jr: ok, fair enough
 802016-07-20T01:00:03  <gmaxwell> luke-jr: the _current_ unmodified bytes per sigops blocks some bare multisig usage.
 812016-07-20T01:00:15  <luke-jr> gmaxwell: accidentally
 822016-07-20T01:00:22  <gmaxwell> Sure. It's a bug, we need to fix it.
 832016-07-20T01:00:34  <luke-jr> so we fix that, and independently add sipa's policy.
 842016-07-20T01:00:50  <sipa> luke-jr: both together are acceptable, but more complexity, and i'm not sure what it gains
 852016-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.
 862016-07-20T01:01:04  * luke-jr notes 8364 has been suggested as a fix without any controversy for months now.
 872016-07-20T01:01:44  <sipa> but you agree that 8364 (on its own) would be a bad idea?
 882016-07-20T01:02:24  <luke-jr> sipa: I don't believe I have sufficient information to answer that.
 892016-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
 902016-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
 912016-07-20T01:04:37  <gmaxwell> luke-jr: without 8365, 8364 would reintroduct the consensus-sigops block exhaustion attack that was being actively exploited.
 922016-07-20T01:05:00  <sipa> wrt concern about resource usage, we should propose to make bare multisig nonstandard
 932016-07-20T01:07:17  <gmaxwell> we should. But I think thats is seperate, perhaps just as a note in the release notes.
 942016-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
 952016-07-20T01:08:01  <luke-jr> seems just doing 1-of-2 baremultisigs legitimately might actually be an economic concern in the same sense
 962016-07-20T01:08:24  *** jcliff42 has quit IRC
 972016-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
 982016-07-20T01:10:04  <gmaxwell> hah.
 992016-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. :)
1002016-07-20T01:11:08  <luke-jr> mostly on https://github.com/bitcoin/bitcoin/issues/8079
1012016-07-20T01:11:26  <luke-jr> IIRC
1022016-07-20T01:11:40  <luke-jr> maybe it got lost in the other bs on that thread
1032016-07-20T01:11:54  <sipa> i thought 8365 was the obvious fix all the time :)
1042016-07-20T01:12:07  <luke-jr> bbiab
1052016-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)
1062016-07-20T01:13:46  <gmaxwell> I missed 8079's discussion (because it got kind of hostile at some point).
1072016-07-20T01:16:17  *** aalex has quit IRC
1082016-07-20T01:20:22  *** aalex has joined #bitcoin-core-dev
1092016-07-20T01:24:23  *** hsmiths has quit IRC
1102016-07-20T01:27:41  *** hsmiths has joined #bitcoin-core-dev
1112016-07-20T01:32:12  *** Giszmo1 has joined #bitcoin-core-dev
1122016-07-20T01:33:45  *** Giszmo has quit IRC
1132016-07-20T01:42:42  *** aalex has quit IRC
1142016-07-20T01:45:01  *** hsmiths has quit IRC
1152016-07-20T01:45:24  *** aalex has joined #bitcoin-core-dev
1162016-07-20T01:48:54  *** hsmiths has joined #bitcoin-core-dev
1172016-07-20T01:49:05  *** netsin has quit IRC
1182016-07-20T02:01:19  *** achow101 has quit IRC
1192016-07-20T02:01:42  *** achow101 has joined #bitcoin-core-dev
1202016-07-20T02:04:07  *** jcliff42 has joined #bitcoin-core-dev
1212016-07-20T02:19:35  *** moli has joined #bitcoin-core-dev
1222016-07-20T02:21:43  *** molz has quit IRC
1232016-07-20T02:24:56  *** Chris_Stewart_5 has quit IRC
1242016-07-20T02:27:58  *** Samdney has quit IRC
1252016-07-20T02:34:43  *** gribble has quit IRC
1262016-07-20T02:35:40  *** netsin has joined #bitcoin-core-dev
1272016-07-20T02:38:56  *** gribble has joined #bitcoin-core-dev
1282016-07-20T02:40:47  *** alpalp has quit IRC
1292016-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
1302016-07-20T02:44:52  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1312016-07-20T02:46:15  <phantomcircuit> jonasschnelli, fyi qa/rpc-tests/wallet-hd.py passes even when i changed usehd to createhdwallet
1322016-07-20T02:46:30  <phantomcircuit> which means it's broken maybe?
1332016-07-20T02:47:05  *** netsin has quit IRC
1342016-07-20T02:48:04  <phantomcircuit> CHDChain & CKeyMetadata in walletdb.h seem like they could be in wallet.h instead
1352016-07-20T02:48:14  <phantomcircuit> they're not really specific to the walletdb
1362016-07-20T02:48:37  <phantomcircuit> otoh maybe it's reasonable that the abstraction be improved such that they are?
1372016-07-20T02:51:45  *** aalex has quit IRC
1382016-07-20T02:53:16  *** Chris_Stewart_5 has quit IRC
1392016-07-20T02:54:43  *** jcliff42 has quit IRC
1402016-07-20T02:55:21  *** aalex has joined #bitcoin-core-dev
1412016-07-20T02:59:52  *** NicLin has quit IRC
1422016-07-20T03:06:30  *** netsin has joined #bitcoin-core-dev
1432016-07-20T03:08:16  *** Lightsword has quit IRC
1442016-07-20T03:08:20  *** warren has quit IRC
1452016-07-20T03:09:16  *** netsin has quit IRC
1462016-07-20T03:09:49  *** TD-Linux has quit IRC
1472016-07-20T03:11:21  *** warren has joined #bitcoin-core-dev
1482016-07-20T03:12:56  *** Lightsword has joined #bitcoin-core-dev
1492016-07-20T03:14:36  *** TD-Linux has joined #bitcoin-core-dev
1502016-07-20T03:28:12  *** achow101 has quit IRC
1512016-07-20T03:28:34  *** achow101 has joined #bitcoin-core-dev
1522016-07-20T03:35:53  *** PRab has joined #bitcoin-core-dev
1532016-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.
1542016-07-20T04:22:26  <phantomcircuit> sipa: apparently returning a CKey doesn't work?
1552016-07-20T04:22:36  *** moli has quit IRC
1562016-07-20T04:23:48  <phantomcircuit> had to do this to 8375 https://gist.github.com/pstratem/a01c49e3be2a82076d240819e3823f31
1572016-07-20T04:34:33  *** kadoban has quit IRC
1582016-07-20T04:38:38  *** moli has joined #bitcoin-core-dev
1592016-07-20T04:44:46  *** fengling has quit IRC
1602016-07-20T05:13:05  *** fengling has joined #bitcoin-core-dev
1612016-07-20T05:13:28  *** ebfull has joined #bitcoin-core-dev
1622016-07-20T05:21:07  *** aalex has quit IRC
1632016-07-20T05:25:20  *** aalex has joined #bitcoin-core-dev
1642016-07-20T05:31:04  *** dirtynewshoes has quit IRC
1652016-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
1662016-07-20T05:32:45  *** moli has quit IRC
1672016-07-20T05:34:04  *** moli has joined #bitcoin-core-dev
1682016-07-20T05:36:08  *** moli has joined #bitcoin-core-dev
1692016-07-20T05:38:53  *** baldur has quit IRC
1702016-07-20T05:47:08  *** moli has joined #bitcoin-core-dev
1712016-07-20T05:51:19  *** baldur has joined #bitcoin-core-dev
1722016-07-20T06:08:34  *** dirtynewshoes has joined #bitcoin-core-dev
1732016-07-20T06:37:34  *** dirtynewshoes has quit IRC
1742016-07-20T06:42:06  *** fengling has quit IRC
1752016-07-20T06:44:41  *** fengling has joined #bitcoin-core-dev
1762016-07-20T07:04:41  *** dirtynewshoes has joined #bitcoin-core-dev
1772016-07-20T07:10:51  <GitHub21> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/045106b4f13c...c98abf2c7099
1782016-07-20T07:10:51  <GitHub21> bitcoin/master 3b3ce25 Cory Fields: build: fix non-deterministic biplist...
1792016-07-20T07:10:52  <GitHub21> bitcoin/master c98abf2 Wladimir J. van der Laan: Merge #8373: Fix OSX non-deterministic dmg...
1802016-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
1812016-07-20T07:12:06  <GitHub168> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/1fe7f404078121ad370ec955aa23befa322549bb
1822016-07-20T07:12:06  <GitHub168> bitcoin/0.13 1fe7f40 Cory Fields: build: fix non-deterministic biplist...
1832016-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
1842016-07-20T07:16:27  <wumpus> I agree it should be solved obviously
1852016-07-20T07:27:07  *** Guyver2 has joined #bitcoin-core-dev
1862016-07-20T07:42:07  *** Arnavion has quit IRC
1872016-07-20T07:42:29  *** Arnavion has joined #bitcoin-core-dev
1882016-07-20T07:46:14  <phantomcircuit> wumpus, updated the comment in #8378 think it needs to be tagged for 0.13
1892016-07-20T07:50:21  <wumpus> tagged
1902016-07-20T07:58:03  <Raccoon> +--------------+   +--------+   +-----+   +--------+   +------+   +------+   +---+  
1912016-07-20T07:58:04  <Raccoon> | #BITCOIN-DEV |## | MISSES |-  | YOU |\\ | GAVIN, |## | COME |\\ | HOME |-  | ! |::
1922016-07-20T07:58:04  <Raccoon> +--------------+## +--------+ | +-----+\\ +--------+## +------+\\ +------+ | +---+::
1932016-07-20T07:58:04  <Raccoon>   ################   '--------    \\\\\\\   ##########   \\\\\\\\   '------    :::::
1942016-07-20T07:59:06  <luke-jr> !ops
1952016-07-20T07:59:12  *** ChanServ sets mode: +o luke-jr
1962016-07-20T07:59:35  <luke-jr> eh, he's not here? O.o
1972016-07-20T07:59:40  *** luke-jr sets mode: -o luke-jr
1982016-07-20T08:00:18  <phantomcircuit> luke-jr, lol it's a notice and the modes are set wrong
1992016-07-20T08:00:33  <luke-jr> phantomcircuit: modes are set "wrong" because that's how GitHub does commits :x
2002016-07-20T08:00:50  <phantomcircuit> luke-jr, lol
2012016-07-20T08:01:05  <phantomcircuit> i think you can still set a ban to keep him from doing it
2022016-07-20T08:01:21  <luke-jr> hm
2032016-07-20T08:02:23  <jl2012> the signed osx binary seems not deterministic?
2042016-07-20T08:05:15  <wumpus> jl2012: no, the ds_store is not deterministic
2052016-07-20T08:05:24  <wumpus> (which is not part of the signed data, but still affects the hash)
2062016-07-20T08:05:50  <btcdrak> phantomcircuit: no you can set github to come to the channel to post commit notices
2072016-07-20T08:06:14  <wumpus> see https://github.com/bitcoin/bitcoin/pull/8373
2082016-07-20T08:09:21  <jl2012> wumpus: so I should now rebuild for osx?
2092016-07-20T08:09:38  <wumpus> no, we'll just let this slide for rc1, for rc2 it will be solved
2102016-07-20T08:10:07  <jl2012> ok
2112016-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)
2122016-07-20T08:10:21  <kinlo> hmmmz
2132016-07-20T08:10:46  <kinlo> this channel needs to be set +n (no messages from people not on the channel)
2142016-07-20T08:10:59  <kinlo> just make the github clients join the channel
2152016-07-20T08:11:08  <wumpus> then github can't paste into it
2162016-07-20T08:11:15  <btcdrak> wumpus: yes it can
2172016-07-20T08:11:15  <kinlo> github can join...
2182016-07-20T08:11:19  <btcdrak> it's a setting
2192016-07-20T08:11:38  <luke-jr> kinlo: way too spammy
2202016-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
2212016-07-20T08:11:55  <kinlo> luke-jr: and raccoon isn't ?:)
2222016-07-20T08:12:04  <luke-jr> Raccoon can be banned if he does it again
2232016-07-20T08:12:11  <luke-jr> he PM'd me he wouldn't
2242016-07-20T08:12:20  <wumpus> they distribute it over multiple bots, let's just ban the idiot and move on
2252016-07-20T08:12:55  *** ChanServ sets mode: +o wumpus
2262016-07-20T08:13:10  *** wumpus sets mode: +b *!*@unaffiliated/raccoon
2272016-07-20T08:13:17  *** ChanServ sets mode: -o wumpus
2282016-07-20T08:15:31  *** davidlj95 has joined #bitcoin-core-dev
2292016-07-20T08:24:53  *** Guyver2 has quit IRC
2302016-07-20T08:31:41  <jonasschnelli> [23:45:16] <phantomcircuit:#bitcoin-core-dev> jonasschnelli, why does CHDKeyStore::PrivateKeyDerivation take the keypath as a string?
2312016-07-20T08:31:58  <jonasschnelli> phantomcircuit: I guess you are refering to one of my closed PR Bip32 PRs?
2322016-07-20T08:32:19  <jonasschnelli> I think somewhen we need a feature that can derive keys from a given string keypath.
2332016-07-20T08:32:25  *** jannes has joined #bitcoin-core-dev
2342016-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
2352016-07-20T08:33:02  <jonasschnelli> phantomcircuit: usehd=1 is default....
2362016-07-20T08:37:30  *** MarcoFalke has joined #bitcoin-core-dev
2372016-07-20T08:44:30  *** MarcoFalke has left #bitcoin-core-dev
2382016-07-20T08:55:41  *** MarcoFalke has joined #bitcoin-core-dev
2392016-07-20T09:04:32  *** pedrobranco has joined #bitcoin-core-dev
2402016-07-20T09:05:03  *** pedrobranco has joined #bitcoin-core-dev
2412016-07-20T09:06:57  *** MarcoFalke has left #bitcoin-core-dev
2422016-07-20T09:18:06  *** fengling has quit IRC
2432016-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?
2442016-07-20T09:18:53  <jl2012> Now it says "Testnet-only segregated witness" but it affects some mainnet policy
2452016-07-20T09:19:07  <wumpus> jl2012: does it affect users in any way, in practice?
2462016-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
2472016-07-20T09:20:13  <wumpus> it'll just confuse
2482016-07-20T09:20:48  <jl2012> only if someone generates bare segwit outputs. 0.13 will relay and mine these transactions
2492016-07-20T09:21:40  <wumpus> I don't understand, why is that the case for mainnet?
2502016-07-20T09:22:17  <sipa> spending them is non-standard, and won't be relayed before activation
2512016-07-20T09:22:23  <jl2012> because witness outputs are now starndard
2522016-07-20T09:23:00  <jl2012> I'm not talking about spending. I'm talking about sending to segwit outputs
2532016-07-20T09:24:17  <jl2012> precisely, if a scriptPubKey is OP_0 <20/32 bytes>, it becomes standard in 0.13
2542016-07-20T09:25:35  <gmaxwell> He means paying to a segwit output which doesn't use p2sh.
2552016-07-20T09:25:44  <jl2012> yes
2562016-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)
2572016-07-20T09:26:53  <wumpus> so, all in all, it's still useless right now
2582016-07-20T09:26:55  <gmaxwell> I think perhaps we sould leave them non-standard in mainnet until there is an address encoding.
2592016-07-20T09:27:14  <gmaxwell> because it's useless and allowing useless things get dumb behavior enshrined.
2602016-07-20T09:27:38  <wumpus> yes - I guess they could be (mis)used for e.g. data storage?
2612016-07-20T09:28:13  <wumpus> like bare multisig
2622016-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.
2632016-07-20T09:29:54  <jl2012> gmaxwell: I think even LN clients will use p2sh-segwit until there is a new address format?
2642016-07-20T09:30:41  <jl2012> technically speaking, people could use native segwit with BIP70
2652016-07-20T09:30:56  <sipa> right
2662016-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
2672016-07-20T09:31:36  *** btcfan has joined #bitcoin-core-dev
2682016-07-20T09:31:41  <wumpus> I think just not mentioning this is enough to have no one care about it
2692016-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
2702016-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.
2712016-07-20T09:32:30  <wumpus> michagogo: looks like a line starting with #
2722016-07-20T09:32:52  <michagogo> wumpus: yep, makes sense
2732016-07-20T09:33:04  <sipa> michagogo: yeah, the line need rewrapping
2742016-07-20T09:33:15  <michagogo> (That's the 0.13 release notes)
2752016-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.
2762016-07-20T09:34:52  <sipa> should we do that even for segwit relay now?
2772016-07-20T09:34:52  *** pedrobranco has quit IRC
2782016-07-20T09:35:14  *** pedrobranco has joined #bitcoin-core-dev
2792016-07-20T09:36:59  *** pedrobranco has quit IRC
2802016-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.
2812016-07-20T09:37:13  *** pedrobranco has joined #bitcoin-core-dev
2822016-07-20T09:39:11  *** pedrobranco has quit IRC
2832016-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.
2842016-07-20T09:40:06  <sipa> well it's a one-line change
2852016-07-20T09:40:25  <sipa> check bip9 status at tip.GetAncestor(144) instead of at tip
2862016-07-20T09:40:39  <sipa> if you want a day delay
2872016-07-20T09:41:07  *** pedrobranco has joined #bitcoin-core-dev
2882016-07-20T09:48:02  <gmaxwell> well we're not even triggering relay of output creation on activation now.
2892016-07-20T09:48:30  <gmaxwell> (and we can't for p2sh, but I suppose there a potential attacker wouldn't usually know the preimage)
2902016-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
2912016-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
2922016-07-20T09:51:26  <GitHub104> [bitcoin] laanwj pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/1fe7f4040781...f0ff08d7841c
2932016-07-20T09:51:27  <GitHub104> bitcoin/0.13 48b9208 Johnson Lau: Remove duplicated name in release notes
2942016-07-20T09:51:27  <GitHub104> bitcoin/0.13 f0ff08d Wladimir J. van der Laan: Merge #8379: Remove duplicated name in release notes...
2952016-07-20T09:57:55  <GitHub113> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c98abf2c7099...8e048f40cc25
2962016-07-20T09:57:55  <GitHub113> bitcoin/master 6523fca Patrick Strateman: Move SetMinVersion for FEATURE_HD to SetHDMasterKey
2972016-07-20T09:57:56  <GitHub113> bitcoin/master 8e048f4 Wladimir J. van der Laan: Merge #8378: [Wallet]Move SetMinVersion for FEATURE_HD to SetHDMasterKey...
2982016-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
2992016-07-20T09:58:30  <GitHub11> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/ebea65121e6c62f6b6acd79408a681b987126a0d
3002016-07-20T09:58:30  <GitHub11> bitcoin/0.13 ebea651 Patrick Strateman: Move SetMinVersion for FEATURE_HD to SetHDMasterKey...
3012016-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
3022016-07-20T10:14:41  *** fengling has joined #bitcoin-core-dev
3032016-07-20T10:15:06  <jannes> On topic of typos in release notes: "propagation relay" should be "propagation delay", I think.
3042016-07-20T10:16:19  *** MarcoFalke has joined #bitcoin-core-dev
3052016-07-20T10:16:33  <MarcoFalke> jannes: Pull request welcome :)
3062016-07-20T10:17:57  <sipa> jannes: indeed!
3072016-07-20T10:17:57  *** pedrobranco has quit IRC
3082016-07-20T10:19:26  *** fengling has quit IRC
3092016-07-20T10:21:19  *** pedrobranco has joined #bitcoin-core-dev
3102016-07-20T10:25:50  <jonasschnelli> btcdrak: nice! What block storage did you use? SDCard or USBStick? Did you had a corruption(s) during sync?
3112016-07-20T10:28:06  <btcdrak> jonasschnelli: I used a Samsung EVO+ 128MB, no corruption issues.
3122016-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).
3132016-07-20T10:28:56  <jonasschnelli> Did you used prunining?
3142016-07-20T10:29:13  <btcdrak> jonasschnelli: No, no pruning. Full node.
3152016-07-20T10:29:31  <jonasschnelli> Technically with pruning its still a full node. :)
3162016-07-20T10:29:40  <jonasschnelli> Good to know.. I need to try the same on my Pine.
3172016-07-20T10:29:47  <btcdrak> jonasschnelli: It's a fuller node :-p
3182016-07-20T10:29:52  <jonasschnelli> ;-)
3192016-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".
3202016-07-20T10:31:04  *** Cory has quit IRC
3212016-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
3222016-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 :)
3232016-07-20T10:37:34  *** jl2012 has quit IRC
3242016-07-20T10:39:05  *** jl2012 has joined #bitcoin-core-dev
3252016-07-20T10:39:54  <sipa> jannes: looks good
3262016-07-20T10:45:44  *** laurentmt has joined #bitcoin-core-dev
3272016-07-20T10:48:04  *** laurentmt has quit IRC
3282016-07-20T10:48:05  *** pedrobranco has quit IRC
3292016-07-20T10:48:11  *** pedrobranco has joined #bitcoin-core-dev
3302016-07-20T10:50:25  *** pedrobra_ has joined #bitcoin-core-dev
3312016-07-20T10:50:25  *** pedrobranco has quit IRC
3322016-07-20T10:52:19  *** laurentmt has joined #bitcoin-core-dev
3332016-07-20T10:52:19  *** pedrobra_ has quit IRC
3342016-07-20T10:52:34  *** pedrobranco has joined #bitcoin-core-dev
3352016-07-20T10:54:36  *** laurentmt has quit IRC
3362016-07-20T10:54:36  *** pedrobranco has quit IRC
3372016-07-20T10:54:38  *** pedrobra_ has joined #bitcoin-core-dev
3382016-07-20T10:56:32  *** pedrobra_ has quit IRC
3392016-07-20T10:56:57  *** pedrobranco has joined #bitcoin-core-dev
3402016-07-20T10:58:58  *** pedrobra_ has joined #bitcoin-core-dev
3412016-07-20T10:58:58  *** pedrobranco has quit IRC
3422016-07-20T11:00:57  *** pedrobranco has joined #bitcoin-core-dev
3432016-07-20T11:00:57  *** pedrobra_ has quit IRC
3442016-07-20T11:01:25  *** YOU-JI has joined #bitcoin-core-dev
3452016-07-20T11:03:00  *** pedrobra_ has joined #bitcoin-core-dev
3462016-07-20T11:03:00  *** pedrobranco has quit IRC
3472016-07-20T11:04:38  *** pedrobra_ has quit IRC
3482016-07-20T11:05:02  *** pedrobranco has joined #bitcoin-core-dev
3492016-07-20T11:11:08  *** Cory has joined #bitcoin-core-dev
3502016-07-20T11:16:14  *** fengling has joined #bitcoin-core-dev
3512016-07-20T11:21:06  *** fengling has quit IRC
3522016-07-20T11:28:03  *** davidlj95 has left #bitcoin-core-dev
3532016-07-20T11:28:17  *** cryptapus has joined #bitcoin-core-dev
3542016-07-20T11:28:17  *** cryptapus has joined #bitcoin-core-dev
3552016-07-20T11:32:51  *** davec has quit IRC
3562016-07-20T11:38:31  *** davec has joined #bitcoin-core-dev
3572016-07-20T11:38:58  *** Ylbam has joined #bitcoin-core-dev
3582016-07-20T11:52:43  *** pedrobranco has quit IRC
3592016-07-20T11:52:43  *** pedrobra_ has joined #bitcoin-core-dev
3602016-07-20T11:57:02  *** pedrobranco has joined #bitcoin-core-dev
3612016-07-20T11:57:02  *** pedrobra_ has quit IRC
3622016-07-20T11:58:34  *** moli has quit IRC
3632016-07-20T12:03:55  *** pedrobranco has quit IRC
3642016-07-20T12:04:04  *** pedrobranco has joined #bitcoin-core-dev
3652016-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
3662016-07-20T12:18:05  *** fengling has joined #bitcoin-core-dev
3672016-07-20T12:23:06  *** fengling has quit IRC
3682016-07-20T12:27:04  *** pedrobranco has quit IRC
3692016-07-20T12:35:14  *** pedrobranco has joined #bitcoin-core-dev
3702016-07-20T12:48:28  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3712016-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
3722016-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
3732016-07-20T13:15:04  <Chris_Stewart_5> Can't an 'unsigned int' be larger than 4 bytes?
3742016-07-20T13:15:06  *** adamg has quit IRC
3752016-07-20T13:15:44  <sipa> Chris_Stewart_5: no, they're just integers
3762016-07-20T13:16:01  <sipa> Chris_Stewart_5: READWRITE(x) just invokes the serializer/deserializer for x
3772016-07-20T13:16:25  <sipa> vectors are serialized as compactsize(vector.size()), and then a concatenation of all the elements
3782016-07-20T13:16:50  <sipa> and no, the serialization code (so far) relies on unsigned int being 4 bytes
3792016-07-20T13:19:27  *** fengling has joined #bitcoin-core-dev
3802016-07-20T13:19:44  *** laurentmt has joined #bitcoin-core-dev
3812016-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
3822016-07-20T13:21:44  <sipa> the C standard does not fix its size
3832016-07-20T13:21:59  <sipa> but we don't support any architectures where it isn't 4 bytes
3842016-07-20T13:22:48  <Chris_Stewart_5> oh ok, thanks for the clarification
3852016-07-20T13:24:26  *** fengling has quit IRC
3862016-07-20T14:07:20  *** YOU-JI has quit IRC
3872016-07-20T14:10:03  *** pedrobranco has quit IRC
3882016-07-20T14:10:41  *** pedrobranco has joined #bitcoin-core-dev
3892016-07-20T14:12:45  *** monkey_trauma has joined #bitcoin-core-dev
3902016-07-20T14:20:55  *** fengling has joined #bitcoin-core-dev
3912016-07-20T14:24:33  *** zooko has joined #bitcoin-core-dev
3922016-07-20T14:25:46  *** fengling has quit IRC
3932016-07-20T14:29:29  *** moli has joined #bitcoin-core-dev
3942016-07-20T14:32:10  *** kadoban has joined #bitcoin-core-dev
3952016-07-20T14:32:59  *** frankenmint has joined #bitcoin-core-dev
3962016-07-20T14:56:08  *** owowo has quit IRC
3972016-07-20T15:03:08  *** zooko has quit IRC
3982016-07-20T15:12:04  *** Chris_Stewart_5 has quit IRC
3992016-07-20T15:16:12  *** owowo has joined #bitcoin-core-dev
4002016-07-20T15:21:12  *** Amnez777 has joined #bitcoin-core-dev
4012016-07-20T15:21:55  *** harrymm has quit IRC
4022016-07-20T15:22:27  *** fengling has joined #bitcoin-core-dev
4032016-07-20T15:27:13  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4042016-07-20T15:27:26  *** fengling has quit IRC
4052016-07-20T15:41:05  *** harrymm has joined #bitcoin-core-dev
4062016-07-20T15:49:38  *** laurentmt has quit IRC
4072016-07-20T15:50:30  *** netsin has joined #bitcoin-core-dev
4082016-07-20T15:59:08  *** pedrobranco has quit IRC
4092016-07-20T16:01:34  *** pedrobranco has joined #bitcoin-core-dev
4102016-07-20T16:16:39  *** Guyver2 has joined #bitcoin-core-dev
4112016-07-20T16:23:55  *** fengling has joined #bitcoin-core-dev
4122016-07-20T16:28:46  *** fengling has quit IRC
4132016-07-20T16:34:39  *** aalex has quit IRC
4142016-07-20T16:35:24  *** aalex has joined #bitcoin-core-dev
4152016-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
4162016-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".
4172016-07-20T16:52:38  *** zooko has joined #bitcoin-core-dev
4182016-07-20T16:52:56  <sipa> bsm117532: is the witness script known?
4192016-07-20T16:53:10  <sipa> ah, or it's p2wpkh
4202016-07-20T16:58:53  <bsm117532> It's p2wpkh
4212016-07-20T17:00:09  <bsm117532> I bet I'm the only person using *raw* rpc calls with witness txns ;-)
4222016-07-20T17:00:26  <instagibbs> bsm117532, that error should only pop up if it fails VerifyScript?
4232016-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?
4242016-07-20T17:03:33  <bsm117532> I'd think this wouldn't be a failure but should spit out the same transaction with "complete": false
4252016-07-20T17:03:37  <instagibbs> looks like the error for p2wpkh is just checking if the stack is size 2?
4262016-07-20T17:03:44  <instagibbs> if the hash it seems is size 20
4272016-07-20T17:03:47  <instagibbs> sees*
4282016-07-20T17:04:20  <instagibbs> https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L1323
4292016-07-20T17:04:30  <instagibbs> and a few lines before it, for the 32 byte case
4302016-07-20T17:06:49  <bsm117532> instagibbs: Yes, that's it. The witness stack size would be zero (because it's unsigned).
4312016-07-20T17:07:12  <instagibbs> ok so it pushes nothing, and fails later
4322016-07-20T17:09:01  *** pedrobranco has quit IRC
4332016-07-20T17:10:29  <instagibbs> we should just be checking the return value of ProduceSignature, right?
4342016-07-20T17:10:40  <bsm117532> SCRIPT_ERR_WITNESS_PROGRAM_WITNESS_EMPTY is a better error if stack is empty
4352016-07-20T17:12:49  <instagibbs> it's a special case for p2wpkh
4362016-07-20T17:12:54  <instagibbs> not a great error message I agree though
4372016-07-20T17:13:10  * bsm117532 is still trying to grok the VerifyScript line
4382016-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!
4392016-07-20T17:14:42  <bsm117532> (My example only has one input)
4402016-07-20T17:15:44  <bsm117532> What happens with non-segwit p2pkh's here?  Won't they fail too?
4412016-07-20T17:15:58  *** pedrobranco has joined #bitcoin-core-dev
4422016-07-20T17:16:06  <instagibbs> hmm? why would it fail with multiple valid inputs?
4432016-07-20T17:16:19  <bsm117532> Because it signs them one at a time.
4442016-07-20T17:16:23  <instagibbs> they will fail as well, the error here i think is just not helpful
4452016-07-20T17:16:27  <bsm117532> And calls verifyscript after each one
4462016-07-20T17:16:33  <instagibbs> that's how signing works
4472016-07-20T17:17:13  <bsm117532> So if I read this correctly, signrawtransaction would be incapable of signing something with multiple unsigned inputs?
4482016-07-20T17:17:29  <instagibbs> No, it signs anything it can
4492016-07-20T17:18:19  <instagibbs> then checks that script to see if it's satisfied
4502016-07-20T17:18:34  <instagibbs> in our case it's not, but it needs to spit out a better error
4512016-07-20T17:18:43  <bsm117532> The VerifyScript is inside the loop though...
4522016-07-20T17:18:51  <bsm117532> It should be outside.
4532016-07-20T17:19:41  <instagibbs> No, each input scriptSig needs to be checked individually
4542016-07-20T17:20:03  <bsm117532> Oh I see, `i` is passed.
4552016-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.
4562016-07-20T17:25:33  *** fengling has joined #bitcoin-core-dev
4572016-07-20T17:25:40  *** Chris_Stewart_5 has quit IRC
4582016-07-20T17:27:38  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4592016-07-20T17:30:26  *** fengling has quit IRC
4602016-07-20T17:30:58  <instagibbs> bsm117532, it is true that the 32 byte version has an error already for empty witness
4612016-07-20T17:32:24  <instagibbs> seems useful as a debugging message for both
4622016-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.
4632016-07-20T17:34:44  <sipa> sure, the result of signrawtransaction can be complete:false ?
4642016-07-20T17:35:02  <sipa> for example in case of multisig and you only have some of the keys
4652016-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.
4662016-07-20T17:35:44  <bsm117532> I could be reading it wrong though...
4672016-07-20T17:36:50  <sipa> where did you see this error, btw?
4682016-07-20T17:37:14  <bsm117532> Running: bitcoin-cli signrawtransaction
4692016-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
4702016-07-20T17:37:38  <sipa> hmm, that should never return an error
4712016-07-20T17:37:45  <sipa> it should just not sign
4722016-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.
4732016-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
4742016-07-20T17:44:04  <sipa> i don't understand why we call that in the first place
4752016-07-20T17:44:21  <sipa> the only correctness check should be at the end, to determine the value of complete
4762016-07-20T17:44:35  <bsm117532> sipa: I agree
4772016-07-20T17:44:37  <instagibbs> "value of complete"?
4782016-07-20T17:44:55  <bsm117532> instagibbs pointed out that it's a per-input check...
4792016-07-20T17:46:04  *** Samdney has joined #bitcoin-core-dev
4802016-07-20T17:46:20  <instagibbs> bsm117532, did you get back a partially signed txn?
4812016-07-20T17:46:43  <bsm117532> instagibbs: no, it fails.  I'll pastebin it for  you
4822016-07-20T17:46:49  <instagibbs> please do thanks
4832016-07-20T17:47:23  <bsm117532> https://www.zerobin.net/?c6f94fa664089370#rWaua+D/pcl0zvYh8DNwbjfh+XitXfJSNHEOHLscb+A=
4842016-07-20T17:47:33  <instagibbs> "hex"
4852016-07-20T17:47:37  <instagibbs> that's the partially signed
4862016-07-20T17:48:06  <bsm117532> Well it's not signed -- only one input.
4872016-07-20T17:48:10  <instagibbs> errr, yes
4882016-07-20T17:48:20  <instagibbs> but that's expected behavior if you don't have the key
4892016-07-20T17:48:26  <instagibbs> (potentially partially signed)
4902016-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.
4912016-07-20T17:49:12  <instagibbs> kk, agreed
4922016-07-20T17:49:31  *** Chris_Stewart_5 has quit IRC
4932016-07-20T17:49:42  <bsm117532> Now how to get it to say "I don't have the keys..."  ;-)
4942016-07-20T17:50:17  <instagibbs> I think just add the 0 size check like the p2wsh has.
4952016-07-20T17:50:41  <bsm117532> Yes, I did that.  Will include it in my wallet updates.  Thanks!
4962016-07-20T17:50:47  <instagibbs> schweet
4972016-07-20T17:51:15  <instagibbs> do we want to augment TxInErrorToJSON to include witness data as hex?
4982016-07-20T17:52:02  <instagibbs> for a p2w{pkh/sh} we'll be given a blank scriptSig and nothing else
4992016-07-20T17:52:11  <bsm117532> Maybe...the error message is still unclear as to why it failed.
5002016-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...
5012016-07-20T17:56:46  *** Chris_Stewart_5 has joined #bitcoin-core-dev
5022016-07-20T17:58:08  *** pedrobranco has quit IRC
5032016-07-20T17:59:01  *** ebfull has quit IRC
5042016-07-20T18:00:08  *** MarcoFalke has left #bitcoin-core-dev
5052016-07-20T18:01:15  *** pedrobranco has joined #bitcoin-core-dev
5062016-07-20T18:01:16  *** laurentmt has joined #bitcoin-core-dev
5072016-07-20T18:04:29  *** laurentmt has quit IRC
5082016-07-20T18:04:32  <arubi> bsm117532, which address?  the hash160(pubkey)?
5092016-07-20T18:05:17  <bsm117532> Yes.  It's a simple change to ExtractDestination.
5102016-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.
5112016-07-20T18:05:31  <bsm117532> I don't think we can know the destination for P2WPKH though since it uses a 32 bit hash...
5122016-07-20T18:05:31  <arubi> ah yea ^
5132016-07-20T18:05:37  *** pedrobranco has quit IRC
5142016-07-20T18:05:53  <bsm117532> arubi: That's exactly what I just did, compiling now... ;-)
5152016-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
5162016-07-20T18:06:40  <bsm117532> Why not?
5172016-07-20T18:07:03  *** Chris_Stewart_5 has quit IRC
5182016-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
5192016-07-20T18:07:56  <arubi> or, maybe it does have its uses
5202016-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..
5212016-07-20T18:08:44  <bsm117532> I don't understand...the address in the scriptPubKey is the actual destination, and is consensus enforced, no?
5222016-07-20T18:09:08  <arubi> I don't understand the question, sorry
5232016-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?
5242016-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?
5252016-07-20T18:10:19  <arubi> there is no actual address for a witness v0 script, at least afaik
5262016-07-20T18:11:04  <bsm117532> Sure there is, it's that one in the scriptPubKey...unless I'm horribly confused.
5272016-07-20T18:11:35  <arubi> you mean 0x00 0x14 0x<hash160> ?
5282016-07-20T18:11:41  <bsm117532> Yes
5292016-07-20T18:12:00  <arubi> that has no address pattern that I know of, I might be wrong
5302016-07-20T18:12:37  <bsm117532> My tiny patch does this: https://www.zerobin.net/?ad6eb3578c41e566#Sy4WYHvXEqVGSD3+raknP1SfNUzN+KC9AsejLzSIReI=
5312016-07-20T18:12:49  <arubi> right, that's what I did.
5322016-07-20T18:13:08  <bsm117532> What's wrong with this address msFV...?
5332016-07-20T18:13:17  <arubi> it's a p2pkh script address
5342016-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.
5352016-07-20T18:13:59  <arubi> it might help with referencing the private key, because that's how core works, but nothing else
5362016-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
5372016-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?
5382016-07-20T18:16:06  <bsm117532> This scriptPubKey is the only indicator of the destination address...
5392016-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
5402016-07-20T18:17:27  <bsm117532> The new address types BIP for segwit was deferred.  I don't fully understand that...
5412016-07-20T18:17:41  <arubi> there is no address type for v0 and v0 witnesses
5422016-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?
5432016-07-20T18:17:56  <arubi> er, v0/v1
5442016-07-20T18:18:05  *** pedrobranco has joined #bitcoin-core-dev
5452016-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
5462016-07-20T18:19:01  <bsm117532> Sure
5472016-07-20T18:19:09  <arubi> bsm117532, the correct way now is to wrap it in a p2sh
5482016-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
5492016-07-20T18:19:51  <instagibbs> bsm117532, im working on a small PR to print out witness data when errors occur in signing
5502016-07-20T18:20:12  <bsm117532> arubi: FWIW I'm building an application that will be segwit-only.
5512016-07-20T18:20:19  <bsm117532> instagibbs: cool
5522016-07-20T18:20:34  <arubi> bsm117532, what do you need a 1... address for then? :)
5532016-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?
5542016-07-20T18:21:35  <arubi> no no
5552016-07-20T18:21:52  <arubi> a p2wpkh has no address type.  when it gets one, /that/ should be listed in "addresses"
5562016-07-20T18:22:25  *** Chris_Stewart_5 has joined #bitcoin-core-dev
5572016-07-20T18:22:40  *** pedrobranco has quit IRC
5582016-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
5592016-07-20T18:23:23  <bsm117532> So I've been sending funds to P2PKH (hash160) addresses, with segregated witness, and it works fine!
5602016-07-20T18:23:41  <bsm117532> Oh I see what you're saying
5612016-07-20T18:24:08  <arubi> well a v0 witness has a scriptcode just like a p2pkh script, so it verifies the same
5622016-07-20T18:24:31  <bsm117532> arubi: No, a 1...address is a version byte concatenated with the hash160...
5632016-07-20T18:24:47  <bsm117532> and the segregated witness verifies the hash160.
5642016-07-20T18:24:48  <arubi> that's just the encoding, not the actual payment script
5652016-07-20T18:25:08  <bsm117532> Sure
5662016-07-20T18:25:13  <arubi> no, it actually does a p2pkh verification.  hash(pubkey) == hash && scriptsig & pubkey
5672016-07-20T18:25:19  <bsm117532> Yes
5682016-07-20T18:25:28  <bsm117532> Yes the script is implicit.
5692016-07-20T18:25:40  <arubi> but not the address encoding
5702016-07-20T18:26:02  <arubi> the 1.. address encoding is not the correct output.  an eventual v0 script address is
5712016-07-20T18:26:18  <arubi> v0 witness*
5722016-07-20T18:27:00  *** fengling has joined #bitcoin-core-dev
5732016-07-20T18:27:15  <bsm117532> So there is an intent to bring BIP 142 and new address types (eventually) then?
5742016-07-20T18:27:42  <arubi> I don't know.  I hope there will be, so people could use it
5752016-07-20T18:28:01  <arubi> p2wsh(p2pk) is what you want now for about the same functionality
5762016-07-20T18:28:05  <bsm117532> To be clear, I can create and spend P2WPKH funds on testnet, now.
5772016-07-20T18:28:11  <instagibbs> bsm117532, sipa has been working on better address schemes. Not sure when he'll be "done" though :)
5782016-07-20T18:28:17  <bsm117532> I see
5792016-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
5802016-07-20T18:28:55  <arubi> bare scripts*
5812016-07-20T18:30:14  <bsm117532> FYI, `decoderawtransaction` DOES decode V0 witness addresses as I wanted to do above.
5822016-07-20T18:31:46  *** fengling has quit IRC
5832016-07-20T18:31:48  <arubi> now after the patch, or before? :)
5842016-07-20T18:32:08  <bsm117532> now
5852016-07-20T18:32:15  <bsm117532> Oh....
5862016-07-20T18:32:45  <arubi> it's amazing how we've now both walked the same path :P
5872016-07-20T18:32:59  <bsm117532> Hahaa you're right my patch changed that output.
5882016-07-20T18:35:11  *** zooko has quit IRC
5892016-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)
5902016-07-20T18:36:50  <arubi> cheers bsm117532
5912016-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)
5922016-07-20T18:40:04  <GitHub69> [bitcoin] jonasschnelli pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/ebea65121e6c...66dde4edf733
5932016-07-20T18:40:04  <GitHub69> bitcoin/0.13 ea91961 Chris Moore: Fix formatting error...
5942016-07-20T18:40:05  <GitHub69> bitcoin/0.13 66dde4e Jonas Schnelli: Merge #8382: Fix formatting error...
5952016-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
5962016-07-20T18:42:46  <arubi> why not p2sh(p2wsh({p2pk,multisig})) ? much more versatile
5972016-07-20T18:44:29  <bsm117532>  I'm trying to be efficient and this is a non-wallet usage. ;-)
5982016-07-20T18:44:36  <bsm117532> Also, learn segwit by fire...
5992016-07-20T18:46:14  <bsm117532> importpubkey also doesn't cause bitcoind to pick up pure segwit payments... :-/
6002016-07-20T18:50:08  <arubi> bsm117532, I wonder if it'd track it using createwitnessaddress
6012016-07-20T18:51:19  <arubi> well probably not
6022016-07-20T18:51:42  <bsm117532> I don't understand what createwitnessaddress is for...
6032016-07-20T18:52:02  <arubi> oh disregard entirely, you want to track p2wpkh
6042016-07-20T18:52:14  <arubi> it's for creating p2sh(p2wsh(..))
6052016-07-20T18:52:21  <bsm117532> Oh I see
6062016-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 :)
6072016-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!
6082016-07-20T18:56:23  <arubi> oh sure it will index them with txindex
6092016-07-20T18:56:32  <bsm117532> (so gettransaction doesn't work on these P2WPKH -> P2WPKH transactions)
6102016-07-20T18:56:50  <bsm117532> txindex indexes everything, not only things in your wallet?
6112016-07-20T18:56:54  <arubi> you should be using getrawtransaction <txid> 1 ( 1 if you want json)
6122016-07-20T18:58:20  <arubi> gettransaction is handled by the wallet, for wallet txs
6132016-07-20T18:58:43  <bsm117532> arubi saves my bacon, again
6142016-07-20T18:59:01  <arubi> :)
6152016-07-20T19:01:08  <bsm117532> https://www.youtube.com/watch?v=QSHaERIvFNE
6162016-07-20T19:01:19  <bsm117532> "light bulb"
6172016-07-20T19:02:39  *** supasonic has joined #bitcoin-core-dev
6182016-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
6192016-07-20T19:28:33  *** fengling has joined #bitcoin-core-dev
6202016-07-20T19:29:13  <bsm117532> I can test that instagibbs, shall I tACK it?  I'm new to the procedures...
6212016-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
6222016-07-20T19:30:44  <Chris_Stewart_5> https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L1166
6232016-07-20T19:30:55  <gmaxwell> bsm117532: if you've tested and it works you can tested ack.
6242016-07-20T19:31:05  <bsm117532> will do
6252016-07-20T19:31:20  <instagibbs> I just tested the bip143 examples, so please test :)
6262016-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'
6272016-07-20T19:31:47  <Chris_Stewart_5> specifically this is related to some of the tests in sighash.json with really large hash types
6282016-07-20T19:33:06  *** fengling has quit IRC
6292016-07-20T19:35:13  *** netsin has quit IRC
6302016-07-20T19:36:21  <Chris_Stewart_5> wait..
6312016-07-20T19:37:11  <Chris_Stewart_5> nvm
6322016-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?
6332016-07-20T19:39:37  <Chris_Stewart_5> bsm117532: No, it is serialized as a 4 byte integer, I'm confusing myself with something else :-)
6342016-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
6352016-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.
6362016-07-20T19:49:49  *** jtimon has joined #bitcoin-core-dev
6372016-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
6382016-07-20T19:50:11  <bsm117532> After that line adD: if (witness.stack.size() == 0) { return set_error(serror, SCRIPT_ERR_WITNESS_PROGRAM_WITNESS_EMPTY); }
6392016-07-20T19:50:49  <instagibbs> I'm not going to mix debug and consensus PRs ;P
6402016-07-20T19:51:59  <instagibbs> (even though it should be obviously correct)
6412016-07-20T19:52:30  <jtimon> instagibbs: no, use CValidationState and the debugging can be done after the faulied check
6422016-07-20T19:53:43  <jtimon> see https://github.com/bitcoin/bitcoin/pull/8341 for example
6432016-07-20T19:54:09  <jtimon> well, I don't know what you were discussing before, so maybe I got you out of context...
6442016-07-20T19:54:38  <jtimon> oh, debug and consensus *PRs*, never mind
6452016-07-20T19:54:41  * jtimon hides
6462016-07-20T19:56:49  <instagibbs> :P
6472016-07-20T19:58:34  *** mkarrer has quit IRC
6482016-07-20T19:58:43  <bsm117532> I see how it is, make *me* do a consensus PR :-P
6492016-07-20T19:59:30  * instagibbs hides
6502016-07-20T20:01:56  *** mkarrer has joined #bitcoin-core-dev
6512016-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?
6522016-07-20T20:02:39  *** mkarrer has joined #bitcoin-core-dev
6532016-07-20T20:02:40  <Chris_Stewart_5> https://github.com/bitcoin/bitcoin/blob/d612837814020ae832499d18e6ee5eb919a87907/src/script/sign.cpp#L32
6542016-07-20T20:04:34  *** Amnez777 has quit IRC
6552016-07-20T20:05:37  <Chris_Stewart_5> and wherever the number ends up is the procedure that is used?
6562016-07-20T20:06:11  *** cryptapus has quit IRC
6572016-07-20T20:10:44  *** jannes has quit IRC
6582016-07-20T20:11:40  *** Amnez777 has joined #bitcoin-core-dev
6592016-07-20T20:29:32  *** fengling has joined #bitcoin-core-dev
6602016-07-20T20:34:26  *** fengling has quit IRC
6612016-07-20T20:36:00  *** netsin has joined #bitcoin-core-dev
6622016-07-20T20:40:55  *** netsin has quit IRC
6632016-07-20T20:43:00  *** netsin has joined #bitcoin-core-dev
6642016-07-20T20:44:45  *** netsin has quit IRC
6652016-07-20T20:47:43  <sipa> Chris_Stewart_5: hashtype is an integer, so it is serialized as 4 bytes
6662016-07-20T20:51:34  *** frankenmint has quit IRC
6672016-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
6682016-07-20T20:54:05  *** netsin has joined #bitcoin-core-dev
6692016-07-20T20:56:37  *** laurentmt has joined #bitcoin-core-dev
6702016-07-20T20:58:57  *** zooko has joined #bitcoin-core-dev
6712016-07-20T20:59:51  *** laurentmt has quit IRC
6722016-07-20T21:04:53  <sipa> when did segwit activate on testnet?
6732016-07-20T21:06:25  <btcdrak> sipa: Dec 31st
6742016-07-20T21:06:37  <btcdrak> oh wait i misread "segnet"
6752016-07-20T21:07:05  <btcdrak> sipa: activation is listed here: https://github.com/bitcoin/bips/blob/master/bip-0009/assignments.mediawiki
6762016-07-20T21:07:21  <btcdrak> #834624 on testnet
6772016-07-20T21:11:05  <sipa> btcdrak: thanks
6782016-07-20T21:11:11  <sipa> http://bitcoin.stackexchange.com/questions/46606/does-the-bitcoin-testnet3-network-support-segwit-and-op-csv
6792016-07-20T21:11:39  <sipa> maybe we didn't really communicate clearly about that
6802016-07-20T21:15:23  *** netsin has quit IRC
6812016-07-20T21:21:42  *** Samdney has left #bitcoin-core-dev
6822016-07-20T21:25:33  *** spudowiar has joined #bitcoin-core-dev
6832016-07-20T21:31:05  *** fengling has joined #bitcoin-core-dev
6842016-07-20T21:31:44  *** netsin has joined #bitcoin-core-dev
6852016-07-20T21:34:34  *** netsin has quit IRC
6862016-07-20T21:36:06  *** fengling has quit IRC
6872016-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=
6882016-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.
6892016-07-20T21:42:00  <bsm117532> So, it should trigger segwit deserialization.  But bitcoin does not trigger segwit deserialization and I don't see why...
6902016-07-20T21:42:46  *** belcher has joined #bitcoin-core-dev
6912016-07-20T21:45:53  *** monkey_trauma has quit IRC
6922016-07-20T21:55:57  <sipa> bsm117532: fundrawtransaction and decoderawtransaction first attempt to deserialize without witness support
6932016-07-20T21:56:21  <sipa> as those are the only functions that can have a transaction with 0 inputs
6942016-07-20T21:57:42  *** spudowiar has quit IRC
6952016-07-20T21:57:55  *** zooko has quit IRC
6962016-07-20T22:00:37  <bsm117532> Ah I see.
6972016-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.
6982016-07-20T22:02:50  <bsm117532> It looks like this test was in Bitcoin around 0.9x and earlier but was removed.
6992016-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
7002016-07-20T22:03:43  <bsm117532> Has this been a problem for others?
7012016-07-20T22:04:02  <sipa> longer term, there is no need why non-complete-transactions actually need to use the same serialization at all
7022016-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
7032016-07-20T22:04:41  <bsm117532> Good point...
7042016-07-20T22:05:01  <sipa> so we can just come up with a better serialization format for that later
7052016-07-20T22:05:09  <sipa> and get rid of that ambiguity that now exists
7062016-07-20T22:05:23  *** btcfan has quit IRC
7072016-07-20T22:13:08  *** Guyver2_ has joined #bitcoin-core-dev
7082016-07-20T22:14:56  *** Guyver2 has quit IRC
7092016-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.  ;-)
7102016-07-20T22:15:59  <gmaxwell> don't let them get anywhere near biology.
7112016-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
7122016-07-20T22:19:20  *** Avinty_L_ has joined #bitcoin-core-dev
7132016-07-20T22:20:19  *** whphhg_ has joined #bitcoin-core-dev
7142016-07-20T22:20:29  *** Avinty_L_ has quit IRC
7152016-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
7162016-07-20T22:22:44  *** whphhg has quit IRC
7172016-07-20T22:28:58  *** frankenmint has joined #bitcoin-core-dev
7182016-07-20T22:29:30  *** zooko has joined #bitcoin-core-dev
7192016-07-20T22:32:34  *** fengling has joined #bitcoin-core-dev
7202016-07-20T22:34:49  *** mkarrer has quit IRC
7212016-07-20T22:37:26  *** fengling has quit IRC
7222016-07-20T22:42:23  *** mkarrer has joined #bitcoin-core-dev
7232016-07-20T22:43:17  <jtimon> https://github.com/bitcoin/bitcoin/compare/master...jtimon:0.12.99-consensus-trivialish
7242016-07-20T22:43:43  <jtimon> I have way too many PRs open, a link will be better
7252016-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()
7262016-07-20T22:45:01  <jtimon> should be easy to review
7272016-07-20T23:30:03  *** alpalp has joined #bitcoin-core-dev
7282016-07-20T23:30:03  *** alpalp has joined #bitcoin-core-dev
7292016-07-20T23:31:49  *** zooko has quit IRC
7302016-07-20T23:31:58  *** jiggalator has joined #bitcoin-core-dev
7312016-07-20T23:33:43  *** whphhg_ is now known as whphhg
7322016-07-20T23:34:04  *** fengling has joined #bitcoin-core-dev
7332016-07-20T23:37:17  *** jiggalator has quit IRC
7342016-07-20T23:39:06  *** fengling has quit IRC