--- Day changed Wed Jul 20 2016
00:04 -!- dirtynewshoes [~dirtynews@sydnns0115w-156057003104.dhcp-dynamic.FibreOp.ns.bellaliant.net] has joined #bitcoin-core-dev
00:10 < GitHub21> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/045106b4f13c...c98abf2c7099
00:10 < GitHub21> bitcoin/master 3b3ce25 Cory Fields: build: fix non-deterministic biplist...
00:10 < GitHub21> bitcoin/master c98abf2 Wladimir J. van der Laan: Merge #8373: Fix OSX non-deterministic dmg...
00:11 < GitHub99> [bitcoin] laanwj closed pull request #8373: Fix OSX non-deterministic dmg (master...biplist-determinism) https://github.com/bitcoin/bitcoin/pull/8373
00:12 < GitHub168> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/1fe7f404078121ad370ec955aa23befa322549bb
00:12 < GitHub168> bitcoin/0.13 1fe7f40 Cory Fields: build: fix non-deterministic biplist...
00:15 < 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
00:16 < wumpus> I agree it should be solved obviously
00:27 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
00:42 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Remote host closed the connection]
00:42 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
00:46 < phantomcircuit> wumpus, updated the comment in #8378 think it needs to be tagged for 0.13
00:50 < wumpus> tagged
00:58 < Raccoon> +--------------+   +--------+   +-----+   +--------+   +------+   +------+   +---+  
00:58 < Raccoon> | #BITCOIN-DEV |## | MISSES |-  | YOU |\\ | GAVIN, |## | COME |\\ | HOME |-  | ! |::
00:58 < Raccoon> +--------------+## +--------+ | +-----+\\ +--------+## +------+\\ +------+ | +---+::
00:58 < Raccoon>   ################   '--------    \\\\\\\   ##########   \\\\\\\\   '------    :::::
00:59 < luke-jr> !ops
00:59 -!- mode/#bitcoin-core-dev [+o luke-jr] by ChanServ
00:59 <@luke-jr> eh, he's not here? O.o
00:59 -!- mode/#bitcoin-core-dev [-o luke-jr] by luke-jr
01:00 < phantomcircuit> luke-jr, lol it's a notice and the modes are set wrong
01:00 < luke-jr> phantomcircuit: modes are set "wrong" because that's how GitHub does commits :x
01:00 < phantomcircuit> luke-jr, lol
01:01 < phantomcircuit> i think you can still set a ban to keep him from doing it
01:01 < luke-jr> hm
01:02 < jl2012> the signed osx binary seems not deterministic?
01:05 < wumpus> jl2012: no, the ds_store is not deterministic
01:05 < wumpus> (which is not part of the signed data, but still affects the hash)
01:05 < btcdrak> phantomcircuit: no you can set github to come to the channel to post commit notices
01:06 < wumpus> see https://github.com/bitcoin/bitcoin/pull/8373
01:09 < jl2012> wumpus: so I should now rebuild for osx?
01:09 < wumpus> no, we'll just let this slide for rc1, for rc2 it will be solved
01:10 < jl2012> ok
01:10 < wumpus> (it's a change in the build system, not in the descriptor, so you can't easily build rc1 with that change)
01:10 < kinlo> hmmmz
01:10 < kinlo> this channel needs to be set +n (no messages from people not on the channel)
01:10 < kinlo> just make the github clients join the channel
01:11 < wumpus> then github can't paste into it
01:11 < btcdrak> wumpus: yes it can
01:11 < kinlo> github can join...
01:11 < btcdrak> it's a setting 
01:11 < luke-jr> kinlo: way too spammy
01:11 < wumpus> I know, we had that in the beginning, but then github bots will be joining and parting all the time
01:11 < kinlo> luke-jr: and raccoon isn't ?:)
01:12 < luke-jr> Raccoon can be banned if he does it again
01:12 < luke-jr> he PM'd me he wouldn't
01:12 < wumpus> they distribute it over multiple bots, let's just ban the idiot and move on
01:12 -!- mode/#bitcoin-core-dev [+o wumpus] by ChanServ
01:13 -!- mode/#bitcoin-core-dev [+b *!*@unaffiliated/raccoon] by wumpus
01:13 -!- mode/#bitcoin-core-dev [-o wumpus] by ChanServ
01:15 -!- davidlj95 [~davidlj95@deic-dyn-232.uab.es] has joined #bitcoin-core-dev
01:24 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
01:31 < jonasschnelli> [23:45:16] <phantomcircuit:#bitcoin-core-dev> jonasschnelli, why does CHDKeyStore::PrivateKeyDerivation take the keypath as a string?
01:31 < jonasschnelli> phantomcircuit: I guess you are refering to one of my closed PR Bip32 PRs?
01:32 < jonasschnelli> I think somewhen we need a feature that can derive keys from a given string keypath.
01:32 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev
01:32 < 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
01:33 < jonasschnelli> phantomcircuit: usehd=1 is default....
01:37 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev
01:44 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev []
01:55 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev
02:04 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
02:04 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Remote host closed the connection]
02:05 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
02:06 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev []
02:18 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
02:18 < jl2012> wumpus: v0 witness program scriptPubKey becomes standard before activation even in mainnet. Do we need to mention this in release notes?
02:18 < jl2012> Now it says "Testnet-only segregated witness" but it affects some mainnet policy
02:19 < wumpus> jl2012: does it affect users in any way, in practice?
02:19 < 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
02:20 < wumpus> it'll just confuse
02:20 < jl2012> only if someone generates bare segwit outputs. 0.13 will relay and mine these transactions
02:21 < wumpus> I don't understand, why is that the case for mainnet?
02:22 < sipa> spending them is non-standard, and won't be relayed before activation
02:22 < jl2012> because witness outputs are now starndard
02:23 < jl2012> I'm not talking about spending. I'm talking about sending to segwit outputs
02:24 < jl2012> precisely, if a scriptPubKey is OP_0 <20/32 bytes>, it becomes standard in 0.13
02:25 < gmaxwell> He means paying to a segwit output which doesn't use p2sh.
02:25 < jl2012> yes
02:26 < 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)
02:26 < wumpus> so, all in all, it's still useless right now
02:26 < gmaxwell> I think perhaps we sould leave them non-standard in mainnet until there is an address encoding.
02:27 < gmaxwell> because it's useless and allowing useless things get dumb behavior enshrined.
02:27 < wumpus> yes - I guess they could be (mis)used for e.g. data storage?
02:28 < wumpus> like bare multisig 
02:29 < 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.
02:29 < jl2012> gmaxwell: I think even LN clients will use p2sh-segwit until there is a new address format?
02:30 < jl2012> technically speaking, people could use native segwit with BIP70
02:30 < sipa> right
02:31 < wumpus> I'm not sure standardness is meant as a way to prevent people from doing something stupid if they try very hard
02:31 -!- btcfan [~dellu2410@93-47-91-145.ip112.fastwebnet.it] has joined #bitcoin-core-dev
02:31 < wumpus> I think just not mentioning this is enough to have no one care about it
02:31 < michagogo> There seems to be some unintentional markup going on here. https://usercontent.irccloud-cdn.com/file/1WImycPE/IMG_0002.PNG
02:32 < gmaxwell> jl2012: yea, but not on a network without any segwit support-- fair that I should back that until segwit is working.
02:32 < wumpus> michagogo: looks like a line starting with #
02:32 < michagogo> wumpus: yep, makes sense
02:33 < sipa> michagogo: yeah, the line need rewrapping
02:33 < michagogo> (That's the 0.13 release notes)
02:33 < 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.
02:34 < sipa> should we do that even for segwit relay now?
02:34 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer]
02:35 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
02:36 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer]
02:37 < 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.
02:37 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
02:39 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer]
02:39 < 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.
02:40 < sipa> well it's a one-line change
02:40 < sipa> check bip9 status at tip.GetAncestor(144) instead of at tip
02:40 < sipa> if you want a day delay
02:41 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
02:48 < gmaxwell> well we're not even triggering relay of output creation on activation now.
02:48 < gmaxwell> (and we can't for p2sh, but I suppose there a potential attacker wouldn't usually know the preimage)
02:48 < GitHub102> [bitcoin] jl2012 opened pull request #8379: Remove duplicated name in release notes (0.13...patch-14) https://github.com/bitcoin/bitcoin/pull/8379
02:51 < GitHub109> [bitcoin] laanwj closed pull request #8379: Remove duplicated name in release notes (0.13...patch-14) https://github.com/bitcoin/bitcoin/pull/8379
02:51 < GitHub104> [bitcoin] laanwj pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/1fe7f4040781...f0ff08d7841c
02:51 < GitHub104> bitcoin/0.13 48b9208 Johnson Lau: Remove duplicated name in release notes
02:51 < GitHub104> bitcoin/0.13 f0ff08d Wladimir J. van der Laan: Merge #8379: Remove duplicated name in release notes...
02:57 < GitHub113> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c98abf2c7099...8e048f40cc25
02:57 < GitHub113> bitcoin/master 6523fca Patrick Strateman: Move SetMinVersion for FEATURE_HD to SetHDMasterKey
02:57 < GitHub113> bitcoin/master 8e048f4 Wladimir J. van der Laan: Merge #8378: [Wallet]Move SetMinVersion for FEATURE_HD to SetHDMasterKey...
02:58 < 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
02:58 < GitHub11> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/ebea65121e6c62f6b6acd79408a681b987126a0d
02:58 < GitHub11> bitcoin/0.13 ebea651 Patrick Strateman: Move SetMinVersion for FEATURE_HD to SetHDMasterKey...
03:07 < 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
03:14 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
03:15 < jannes> On topic of typos in release notes: "propagation relay" should be "propagation delay", I think.
03:16 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev
03:16 < MarcoFalke> jannes: Pull request welcome :)
03:17 < sipa> jannes: indeed!
03:17 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer]
03:19 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
03:21 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
03:25 < jonasschnelli> btcdrak: nice! What block storage did you use? SDCard or USBStick? Did you had a corruption(s) during sync?
03:28 < btcdrak> jonasschnelli: I used a Samsung EVO+ 128MB, no corruption issues.
03:28 < jonasschnelli> btcdrak: Okay. I guess the bigger the SDCard space the less corruptions you will see (even if you don't use the space).
03:28 < jonasschnelli> Did you used prunining?
03:29 < btcdrak> jonasschnelli: No, no pruning. Full node.
03:29 < jonasschnelli> Technically with pruning its still a full node. :)
03:29 < jonasschnelli> Good to know.. I need to try the same on my Pine.
03:29 < btcdrak> jonasschnelli: It's a fuller node :-p
03:29 < jonasschnelli> ;-)
03:30 < jonasschnelli> We should sell Pine64 together with a nice case and some webbase control center for 50$ as "your bank at home".
03:31 -!- Cory [~C@unaffiliated/cory] has quit [Ping timeout: 264 seconds]
03:33 < GitHub70> [bitcoin] jafaber opened pull request #8380: fix typo: propagation relay -> delay (0.13...patch-1) https://github.com/bitcoin/bitcoin/pull/8380
03:35 < 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 :)
03:37 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-fetyvlpepnntxfnf] has quit [Ping timeout: 240 seconds]
03:39 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-srvjqvpmonluxbei] has joined #bitcoin-core-dev
03:39 < sipa> jannes: looks good
03:45 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
03:48 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
03:48 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer]
03:48 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
03:50 -!- pedrobra_ [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
03:50 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer]
03:52 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
03:52 -!- pedrobra_ [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer]
03:52 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
03:54 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
03:54 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer]
03:54 -!- pedrobra_ [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
03:56 -!- pedrobra_ [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer]
03:56 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
03:58 -!- pedrobra_ [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
03:58 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer]
04:00 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
04:00 -!- pedrobra_ [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer]
04:01 -!- YOU-JI [~youyouyou@FL1-125-195-44-154.chb.mesh.ad.jp] has joined #bitcoin-core-dev
04:03 -!- pedrobra_ [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
04:03 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer]
04:04 -!- pedrobra_ [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer]
04:05 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
04:11 -!- Cory [~C@unaffiliated/cory] has joined #bitcoin-core-dev
04:16 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
04:21 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
04:28 -!- davidlj95 [~davidlj95@deic-dyn-232.uab.es] has left #bitcoin-core-dev []
04:28 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
04:32 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer]
04:38 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
04:38 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-shywxegtxovkkxrq] has joined #bitcoin-core-dev
04:52 -!- pedrobra_ [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
04:52 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer]
04:57 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
04:57 -!- pedrobra_ [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer]
04:58 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
05:03 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer]
05:04 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
05:15 < GitHub65> [bitcoin] jl2012 opened pull request #8381: Make witness v0 outputs non-standard (master...patch-15) https://github.com/bitcoin/bitcoin/pull/8381
05:18 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
05:23 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
05:27 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit []
05:35 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
05:48 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
06:03 < 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
06:14 < 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
06:15 < Chris_Stewart_5> Can't an 'unsigned int' be larger than 4 bytes? 
06:15 -!- adamg [~akg@50.242.93.33] has quit [Ping timeout: 276 seconds]
06:15 < sipa> Chris_Stewart_5: no, they're just integers
06:16 < sipa> Chris_Stewart_5: READWRITE(x) just invokes the serializer/deserializer for x
06:16 < sipa> vectors are serialized as compactsize(vector.size()), and then a concatenation of all the elements
06:16 < sipa> and no, the serialization code (so far) relies on unsigned int being 4 bytes
06:19 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
06:19 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
06:20 < Chris_Stewart_5> Hmm some how I got in my head that 'unsigned int' size isn't constant, looks like I was wrong
06:21 < sipa> the C standard does not fix its size
06:21 < sipa> but we don't support any architectures where it isn't 4 bytes
06:22 < Chris_Stewart_5> oh ok, thanks for the clarification
06:24 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
07:07 -!- YOU-JI [~youyouyou@FL1-125-195-44-154.chb.mesh.ad.jp] has quit [Quit: Leaving...]
07:10 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Remote host closed the connection]
07:10 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
07:12 -!- monkey_trauma [~user@185.103.96.143] has joined #bitcoin-core-dev
07:20 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
07:24 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-core-dev
07:25 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
07:29 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
07:32 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev
07:32 -!- frankenmint [~frankenmi@174-25-9-165.ptld.qwest.net] has joined #bitcoin-core-dev
07:56 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Read error: Connection reset by peer]
08:03 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Ping timeout: 258 seconds]
08:12 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
08:16 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
08:21 -!- Amnez777 [~Amnez777@37.157.216.155] has joined #bitcoin-core-dev
08:21 -!- harrymm [~wayne@37.58.59.76] has quit [Ping timeout: 252 seconds]
08:22 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
08:27 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
08:27 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
08:41 -!- harrymm [~wayne@223.204.250.148] has joined #bitcoin-core-dev
08:49 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
08:50 -!- netsin [~jiggalato@unaffiliated/jiggalator] has joined #bitcoin-core-dev
08:59 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Remote host closed the connection]
09:01 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
09:16 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
09:23 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
09:28 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
09:34 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 276 seconds]
09:35 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev
09:37 < GitHub104> [bitcoin] dooglus opened pull request #8382: Fix formatting error (0.13...patch-4) https://github.com/bitcoin/bitcoin/pull/8382
09:50 < 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".
09:52 -!- zooko [~user@50.246.213.170] has joined #bitcoin-core-dev
09:52 < sipa> bsm117532: is the witness script known?
09:53 < sipa> ah, or it's p2wpkh
09:58 < bsm117532> It's p2wpkh
10:00 < bsm117532> I bet I'm the only person using *raw* rpc calls with witness txns ;-)
10:00 < instagibbs> bsm117532, that error should only pop up if it fails VerifyScript?
10:03 < 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?
10:03 < bsm117532> I'd think this wouldn't be a failure but should spit out the same transaction with "complete": false
10:03 < instagibbs> looks like the error for p2wpkh is just checking if the stack is size 2?
10:03 < instagibbs> if the hash it seems is size 20
10:03 < instagibbs> sees*
10:04 < instagibbs> https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L1323
10:04 < instagibbs> and a few lines before it, for the 32 byte case
10:06 < bsm117532> instagibbs: Yes, that's it. The witness stack size would be zero (because it's unsigned).
10:07 < instagibbs> ok so it pushes nothing, and fails later
10:09 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Remote host closed the connection]
10:10 < instagibbs> we should just be checking the return value of ProduceSignature, right?
10:10 < bsm117532> SCRIPT_ERR_WITNESS_PROGRAM_WITNESS_EMPTY is a better error if stack is empty
10:12 < instagibbs> it's a special case for p2wpkh
10:12 < instagibbs> not a great error message I agree though
10:13  * bsm117532 is still trying to grok the VerifyScript line
10:14 < 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!
10:14 < bsm117532> (My example only has one input)
10:15 < bsm117532> What happens with non-segwit p2pkh's here?  Won't they fail too?
10:15 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
10:16 < instagibbs> hmm? why would it fail with multiple valid inputs?
10:16 < bsm117532> Because it signs them one at a time.
10:16 < instagibbs> they will fail as well, the error here i think is just not helpful
10:16 < bsm117532> And calls verifyscript after each one
10:16 < instagibbs> that's how signing works
10:17 < bsm117532> So if I read this correctly, signrawtransaction would be incapable of signing something with multiple unsigned inputs?
10:17 < instagibbs> No, it signs anything it can
10:18 < instagibbs> then checks that script to see if it's satisfied
10:18 < instagibbs> in our case it's not, but it needs to spit out a better error
10:18 < bsm117532> The VerifyScript is inside the loop though...
10:18 < bsm117532> It should be outside.
10:19 < instagibbs> No, each input scriptSig needs to be checked individually 
10:20 < bsm117532> Oh I see, `i` is passed.
10:22 < bsm117532> Does anyone have a good WIP to incorporate that change?  I can fix it with my segwit wallet improvements if not.
10:25 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
10:25 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds]
10:27 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
10:30 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
10:30 < instagibbs> bsm117532, it is true that the 32 byte version has an error already for empty witness
10:32 < instagibbs> seems useful as a debugging message for both
10:32 < 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.
10:34 < sipa> sure, the result of signrawtransaction can be complete:false ?
10:35 < sipa> for example in case of multisig and you only have some of the keys
10:35 < bsm117532> I agree that's logically what it *should* do, but that VerifyScript called for each input fails if it's unsigned.
10:35 < bsm117532> I could be reading it wrong though...
10:36 < sipa> where did you see this error, btw?
10:37 < bsm117532> Running: bitcoin-cli signrawtransaction
10:37 < bsm117532> for a key that isn't in my wallet.  It's a simple one input, one output txn, both p2wpkh
10:37 < sipa> hmm, that should never return an error
10:37 < sipa> it should just not sign
10:41 < 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.
10:42 < bsm117532> Could we remove SCRIPT_VERIFY_WITNESS from this call? https://github.com/bitcoin/bitcoin/blob/master/src/rpc/rawtransaction.cpp#L821
10:44 < sipa> i don't understand why we call that in the first place
10:44 < sipa> the only correctness check should be at the end, to determine the value of complete
10:44 < bsm117532> sipa: I agree
10:44 < instagibbs> "value of complete"?
10:44 < bsm117532> instagibbs pointed out that it's a per-input check...
10:46 -!- Samdney [~Samdney@maus.hawo.stw.uni-erlangen.de] has joined #bitcoin-core-dev
10:46 < instagibbs> bsm117532, did you get back a partially signed txn?
10:46 < bsm117532> instagibbs: no, it fails.  I'll pastebin it for  you
10:46 < instagibbs> please do thanks
10:47 < bsm117532> https://www.zerobin.net/?c6f94fa664089370#rWaua+D/pcl0zvYh8DNwbjfh+XitXfJSNHEOHLscb+A=
10:47 < instagibbs> "hex"
10:47 < instagibbs> that's the partially signed
10:48 < bsm117532> Well it's not signed -- only one input.
10:48 < instagibbs> errr, yes
10:48 < instagibbs> but that's expected behavior if you don't have the key
10:48 < instagibbs> (potentially partially signed)
10:49 < 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.
10:49 < instagibbs> kk, agreed
10:49 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
10:49 < bsm117532> Now how to get it to say "I don't have the keys..."  ;-)
10:50 < instagibbs> I think just add the 0 size check like the p2wsh has.
10:50 < bsm117532> Yes, I did that.  Will include it in my wallet updates.  Thanks!
10:50 < instagibbs> schweet
10:51 < instagibbs> do we want to augment TxInErrorToJSON to include witness data as hex?
10:52 < instagibbs> for a p2w{pkh/sh} we'll be given a blank scriptSig and nothing else
10:52 < bsm117532> Maybe...the error message is still unclear as to why it failed.
10:52 < 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...
10:56 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
10:58 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Remote host closed the connection]
10:59 -!- ebfull [~sean@c-50-170-183-94.hsd1.co.comcast.net] has quit [Remote host closed the connection]
11:00 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev []
11:01 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
11:01 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
11:04 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
11:04 < arubi> bsm117532, which address?  the hash160(pubkey)?
11:05 < bsm117532> Yes.  It's a simple change to ExtractDestination.
11:05 < 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.
11:05 < arubi> ah yea ^
11:05 < bsm117532> I don't think we can know the destination for P2WPKH though since it uses a 32 bit hash...
11:05 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Ping timeout: 260 seconds]
11:05 < bsm117532> arubi: That's exactly what I just did, compiling now... ;-)
11:06 < 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
11:06 < bsm117532> Why not?
11:07 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
11:07 < 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
11:07 < arubi> or, maybe it does have its uses
11:08 < 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..
11:08 < bsm117532> I don't understand...the address in the scriptPubKey is the actual destination, and is consensus enforced, no?
11:09 < arubi> I don't understand the question, sorry
11:09 < 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?
11:09 < 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?
11:10 < arubi> there is no actual address for a witness v0 script, at least afaik
11:11 < bsm117532> Sure there is, it's that one in the scriptPubKey...unless I'm horribly confused.
11:11 < arubi> you mean 0x00 0x14 0x<hash160> ?
11:11 < bsm117532> Yes
11:12 < arubi> that has no address pattern that I know of, I might be wrong
11:12 < bsm117532> My tiny patch does this: https://www.zerobin.net/?ad6eb3578c41e566#Sy4WYHvXEqVGSD3+raknP1SfNUzN+KC9AsejLzSIReI=
11:12 < arubi> right, that's what I did.
11:13 < bsm117532> What's wrong with this address msFV...?
11:13 < arubi> it's a p2pkh script address
11:13 < bsm117532> So?  it's the corresponding input that determines that a segregated witness needs to be used, not the address itself.
11:13 < arubi> it might help with referencing the private key, because that's how core works, but nothing else
11:15 < arubi> I agree that it has some value to a power user, but it's confusing at best to anyone else
11:15 < bsm117532> How could it possibly be confusing?  Is there any chance that the privkey corresponding to msFV... does not control the sent funds?
11:16 < bsm117532> This scriptPubKey is the only indicator of the destination address...
11:16 < arubi> it's not about that, listing that address will make folks accidentally accept payments to both v0 witnesses /and/ that p2pkh script
11:17 < bsm117532> The new address types BIP for segwit was deferred.  I don't fully understand that...
11:17 < arubi> there is no address type for v0 and v0 witnesses
11:17 < 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?
11:17 < arubi> er, v0/v1
11:18 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev
11:18 < arubi> no one is going to accept payments to segwit scripts unless they actually know what they're doing, at least at first
11:19 < bsm117532> Sure
11:19 < arubi> bsm117532, the correct way now is to wrap it in a p2sh
11:19 < bsm117532> Well without this decoding step, `decoderawtransaction` gives absolutely no indication of the destination...which is why I want to decode it.  :-P
11:19 < instagibbs> bsm117532, im working on a small PR to print out witness data when errors occur in signing
11:20 < bsm117532> arubi: FWIW I'm building an application that will be segwit-only.
11:20 < bsm117532> instagibbs: cool
11:20 < arubi> bsm117532, what do you need a 1... address for then? :)
11:21 < 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?
11:21 < arubi> no no
11:21 < arubi> a p2wpkh has no address type.  when it gets one, /that/ should be listed in "addresses"
11:22 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
11:22 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has quit [Ping timeout: 264 seconds]
11:23 < 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
11:23 < bsm117532> So I've been sending funds to P2PKH (hash160) addresses, with segregated witness, and it works fine!
11:23 < bsm117532> Oh I see what you're saying
11:24 < arubi> well a v0 witness has a scriptcode just like a p2pkh script, so it verifies the same
11:24 < bsm117532> arubi: No, a 1...address is a version byte concatenated with the hash160...
11:24 < bsm117532> and the segregated witness verifies the hash160.
11:24 < arubi> that's just the encoding, not the actual payment script
11:25 < bsm117532> Sure
11:25 < arubi> no, it actually does a p2pkh verification.  hash(pubkey) == hash && scriptsig & pubkey
11:25 < bsm117532> Yes
11:25 < bsm117532> Yes the script is implicit.
11:25 < arubi> but not the address encoding
11:26 < arubi> the 1.. address encoding is not the correct output.  an eventual v0 script address is
11:26 < arubi> v0 witness*
11:27 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
11:27 < bsm117532> So there is an intent to bring BIP 142 and new address types (eventually) then?
11:27 < arubi> I don't know.  I hope there will be, so people could use it
11:28 < arubi> p2wsh(p2pk) is what you want now for about the same functionality
11:28 < bsm117532> To be clear, I can create and spend P2WPKH funds on testnet, now.
11:28 < instagibbs> bsm117532, sipa has been working on better address schemes. Not sure when he'll be "done" though :)
11:28 < bsm117532> I see
11:28 < arubi> yes, spend to bare sigs and redeem them, it's all possible. but a simple wallet couldn't send /to/ you
11:28 < arubi> bare scripts*
11:30 < bsm117532> FYI, `decoderawtransaction` DOES decode V0 witness addresses as I wanted to do above.
11:31 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
11:31 < arubi> now after the patch, or before? :)
11:32 < bsm117532> now
11:32 < bsm117532> Oh....
11:32 < arubi> it's amazing how we've now both walked the same path :P
11:32 < bsm117532> Hahaa you're right my patch changed that output.
11:35 -!- zooko [~user@50.246.213.170] has quit [Ping timeout: 240 seconds]
11:35 < 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)
11:36 < arubi> cheers bsm117532 
11:38 < bsm117532> I guess what I need to do is to get bitcoind to add a single txn to its txindex.  (Or use P2SH embedding)
11:40 < GitHub69> [bitcoin] jonasschnelli pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/ebea65121e6c...66dde4edf733
11:40 < GitHub69> bitcoin/0.13 ea91961 Chris Moore: Fix formatting error...
11:40 < GitHub69> bitcoin/0.13 66dde4e Jonas Schnelli: Merge #8382: Fix formatting error...
11:40 < GitHub22> [bitcoin] jonasschnelli closed pull request #8382: Fix formatting error (0.13...patch-4) https://github.com/bitcoin/bitcoin/pull/8382
11:42 < arubi> why not p2sh(p2wsh({p2pk,multisig})) ? much more versatile
11:44 < bsm117532>  I'm trying to be efficient and this is a non-wallet usage. ;-)
11:44 < bsm117532> Also, learn segwit by fire...
11:46 < bsm117532> importpubkey also doesn't cause bitcoind to pick up pure segwit payments... :-/
11:50 < arubi> bsm117532, I wonder if it'd track it using createwitnessaddress
11:51 < arubi> well probably not
11:51 < bsm117532> I don't understand what createwitnessaddress is for...
11:52 < arubi> oh disregard entirely, you want to track p2wpkh
11:52 < arubi> it's for creating p2sh(p2wsh(..))
11:52 < bsm117532> Oh I see
11:55 < arubi> what about tracking using bip32?  that's what I'm doing now so suddenly I think it's good for everything :)
11:56 < 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!
11:56 < arubi> oh sure it will index them with txindex
11:56 < bsm117532> (so gettransaction doesn't work on these P2WPKH -> P2WPKH transactions)
11:56 < bsm117532> txindex indexes everything, not only things in your wallet?
11:56 < arubi> you should be using getrawtransaction <txid> 1 ( 1 if you want json)
11:57 < arubi> gettransaction is handled by the wallet, for wallet txs
11:58 < bsm117532> arubi saves my bacon, again
11:59 < arubi> :)
12:01 < bsm117532> https://www.youtube.com/watch?v=QSHaERIvFNE
12:01 < bsm117532> "light bulb"
12:02 -!- supasonic [~supasonic@172-11-188-177.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev
12:15 < GitHub167> [bitcoin] instagibbs opened pull request #8384: Add witness data output to TxInError messages (master...txinerr) https://github.com/bitcoin/bitcoin/pull/8384
12:28 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
12:29 < bsm117532> I can test that instagibbs, shall I tACK it?  I'm new to the procedures...
12:30 < 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 
12:30 < Chris_Stewart_5> https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L1166
12:30 < gmaxwell> bsm117532: if you've tested and it works you can tested ack.
12:31 < bsm117532> will do
12:31 < instagibbs> I just tested the bip143 examples, so please test :)
12:31 < 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' 
12:31 < Chris_Stewart_5> specifically this is related to some of the tests in sighash.json with really large hash types
12:33 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
12:35 -!- netsin [~jiggalato@unaffiliated/jiggalator] has quit [Remote host closed the connection]
12:36 < Chris_Stewart_5> wait.. 
12:37 < Chris_Stewart_5> nvm
12:38 < bsm117532> Chris_Stewart_5: that's going to get serialized as a varint if nHashType is very large, isn't it?
12:39 < Chris_Stewart_5> bsm117532: No, it is serialized as a 4 byte integer, I'm confusing myself with something else :-) 
12:42 < 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
12:42  * 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.
12:49 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
12:49 < 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
12:50 < bsm117532> After that line adD: if (witness.stack.size() == 0) { return set_error(serror, SCRIPT_ERR_WITNESS_PROGRAM_WITNESS_EMPTY); }
12:50 < instagibbs> I'm not going to mix debug and consensus PRs ;P
12:51 < instagibbs> (even though it should be obviously correct)
12:52 < jtimon> instagibbs: no, use CValidationState and the debugging can be done after the faulied check
12:53 < jtimon> see https://github.com/bitcoin/bitcoin/pull/8341 for example
12:54 < jtimon> well, I don't know what you were discussing before, so maybe I got you out of context...
12:54 < jtimon> oh, debug and consensus *PRs*, never mind
12:54  * jtimon hides
12:56 < instagibbs> :P
12:58 -!- mkarrer [~mkarrer@142.red-83-47-107.dynamicip.rima-tde.net] has quit [Ping timeout: 240 seconds]
12:58 < bsm117532> I see how it is, make *me* do a consensus PR :-P
12:59  * instagibbs hides
13:01 -!- mkarrer [~mkarrer@142.red-83-47-107.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
13:02 -!- mkarrer [~mkarrer@142.red-83-47-107.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
13:02 < 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? 
13:02 -!- mkarrer [~mkarrer@142.red-83-47-107.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
13:02 < Chris_Stewart_5> https://github.com/bitcoin/bitcoin/blob/d612837814020ae832499d18e6ee5eb919a87907/src/script/sign.cpp#L32
13:04 -!- Amnez777 [~Amnez777@37.157.216.155] has quit [Ping timeout: 240 seconds]
13:05 < Chris_Stewart_5> and wherever the number ends up is the procedure that is used? 
13:06 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 240 seconds]
13:10 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]
13:11 -!- Amnez777 [~Amnez777@37.157.216.155] has joined #bitcoin-core-dev
13:29 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
13:34 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
13:36 -!- netsin [~jiggalato@unaffiliated/jiggalator] has joined #bitcoin-core-dev
13:40 -!- netsin [~jiggalato@unaffiliated/jiggalator] has quit [Ping timeout: 252 seconds]
13:43 -!- netsin [~jiggalato@unaffiliated/jiggalator] has joined #bitcoin-core-dev
13:44 -!- netsin [~jiggalato@unaffiliated/jiggalator] has quit [Remote host closed the connection]
13:47 < sipa> Chris_Stewart_5: hashtype is an integer, so it is serialized as 4 bytes
13:51 -!- frankenmint [~frankenmi@174-25-9-165.ptld.qwest.net] has quit [Remote host closed the connection]
13:54 < sipa> Chris_Stewart_5: yes, the hash type is one byte, thought it's treated as a 32-bit int in the signature hash
13:54 -!- netsin [~jiggalato@unaffiliated/jiggalator] has joined #bitcoin-core-dev
13:56 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
13:58 -!- zooko [~user@c-73-14-173-69.hsd1.co.comcast.net] has joined #bitcoin-core-dev
13:59 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
14:04 < sipa> when did segwit activate on testnet?
14:06 < btcdrak> sipa: Dec 31st
14:06 < btcdrak> oh wait i misread "segnet"
14:07 < btcdrak> sipa: activation is listed here: https://github.com/bitcoin/bips/blob/master/bip-0009/assignments.mediawiki
14:07 < btcdrak> #834624 on testnet
14:11 < sipa> btcdrak: thanks
14:11 < sipa> http://bitcoin.stackexchange.com/questions/46606/does-the-bitcoin-testnet3-network-support-segwit-and-op-csv
14:11 < sipa> maybe we didn't really communicate clearly about that
14:15 -!- netsin [~jiggalato@unaffiliated/jiggalator] has quit [Remote host closed the connection]
14:21 -!- Samdney [~Samdney@maus.hawo.stw.uni-erlangen.de] has left #bitcoin-core-dev ["Verlassend"]
14:25 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
14:31 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
14:31 -!- netsin [~jiggalato@unaffiliated/jiggalator] has joined #bitcoin-core-dev
14:34 -!- netsin [~jiggalato@unaffiliated/jiggalator] has quit [Client Quit]
14:36 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
14:40 < 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=
14:41 < 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.
14:42 < bsm117532> So, it should trigger segwit deserialization.  But bitcoin does not trigger segwit deserialization and I don't see why...
14:42 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
14:45 -!- monkey_trauma [~user@185.103.96.143] has quit [Ping timeout: 244 seconds]
14:55 < sipa> bsm117532: fundrawtransaction and decoderawtransaction first attempt to deserialize without witness support
14:56 < sipa> as those are the only functions that can have a transaction with 0 inputs
14:57 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: zzzz?]
14:57 -!- zooko [~user@c-73-14-173-69.hsd1.co.comcast.net] has quit [Ping timeout: 252 seconds]
15:00 < bsm117532> Ah I see.
15:01 < 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.
15:02 < bsm117532> It looks like this test was in Bitcoin around 0.9x and earlier but was removed.
15:03 < 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
15:03 < bsm117532> Has this been a problem for others?
15:04 < sipa> longer term, there is no need why non-complete-transactions actually need to use the same serialization at all
15:04 < sipa> and more complex multisig schemes will need a lot more metadata to be passed along betwee  signers, before a valid transaction appears
15:04 < bsm117532> Good point...
15:05 < sipa> so we can just come up with a better serialization format for that later
15:05 < sipa> and get rid of that ambiguity that now exists
15:05 -!- btcfan [~dellu2410@93-47-91-145.ip112.fastwebnet.it] has quit [Read error: Connection reset by peer]
15:13 -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
15:13 -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has quit [Client Quit]
15:14 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection]
15:15 < 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.  ;-)
15:15 < gmaxwell> don't let them get anywhere near biology.
15:16 < GitHub51> [bitcoin] Hektve87 opened pull request #8385: Can't automatically merge (0.8...master) https://github.com/bitcoin/bitcoin/pull/8385
15:19 -!- Avinty_L_ [~quassel@46.13.156.92] has joined #bitcoin-core-dev
15:20 -!- whphhg_ [~whphhg@unaffiliated/whphhg] has joined #bitcoin-core-dev
15:20 -!- Avinty_L_ [~quassel@46.13.156.92] has quit [Read error: Connection reset by peer]
15:21 < GitHub29> [bitcoin] Hektve87 closed pull request #8385: Can't automatically merge (0.8...master) https://github.com/bitcoin/bitcoin/pull/8385
15:22 -!- whphhg [whphhg@gateway/vpn/mullvad/x-xshgsqltironqvsb] has quit [Read error: Connection reset by peer]
15:28 -!- frankenmint [~frankenmi@174-25-9-165.ptld.qwest.net] has joined #bitcoin-core-dev
15:29 -!- zooko [~user@c-73-14-173-69.hsd1.co.comcast.net] has joined #bitcoin-core-dev
15:32 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
15:34 -!- mkarrer [~mkarrer@142.red-83-47-107.dynamicip.rima-tde.net] has quit []
15:37 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
15:42 -!- mkarrer [~mkarrer@142.red-83-47-107.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
15:43 < jtimon> https://github.com/bitcoin/bitcoin/compare/master...jtimon:0.12.99-consensus-trivialish
15:43 < jtimon> I have way too many PRs open, a link will be better
15:44 < jtimon> includes 2 from nicolas dorian (#8342 #8341) and from me (#8348 #8347 #8346 ) and also also passes Consensus::Params instead of calling Params()
15:45 < jtimon> should be easy to review
16:30 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev
16:31 -!- zooko [~user@c-73-14-173-69.hsd1.co.comcast.net] has quit [Ping timeout: 258 seconds]
16:31 -!- jiggalator [~jiggalato@unaffiliated/jiggalator] has joined #bitcoin-core-dev
16:33 -!- whphhg_ is now known as whphhg
16:34 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
16:37 -!- jiggalator [~jiggalato@unaffiliated/jiggalator] has quit [Remote host closed the connection]
16:39 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
17:02 -!- jiggalator [~jiggalato@unaffiliated/jiggalator] has joined #bitcoin-core-dev
17:13 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
17:23 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 250 seconds]
17:34 -!- jiggalator is now known as netsin
17:35 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
17:35 < phantomcircuit> jonasschnelli, can you check 8152 again
17:40 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
17:42 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
17:45 -!- alpalp [~allen@2605:6000:f4d6:d600:1536:1bf4:1ad6:2bd3] has joined #bitcoin-core-dev
17:45 -!- alpalp [~allen@2605:6000:f4d6:d600:1536:1bf4:1ad6:2bd3] has quit [Changing host]
17:45 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev
17:59 < PRab> Is there a way to have github notify you when there is a new tag?
18:00 < PRab> nm, I should know to google first.
18:00 < PRab> https://github.com/bitcoin/bitcoin/tags.atom works
18:03 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
18:05 -!- frankenmint [~frankenmi@174-25-9-165.ptld.qwest.net] has quit [Remote host closed the connection]
18:05 -!- netsin [~jiggalato@unaffiliated/jiggalator] has quit [Remote host closed the connection]
18:08 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 250 seconds]
18:09 -!- netsin [~jiggalato@unaffiliated/jiggalator] has joined #bitcoin-core-dev
18:15 < PRab> Testing 0.13.0rc1 from my gitian build. Looks like it upgraded smoothly from 0.12.1 and is working properly for me (Win7 64bit).
18:15 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-shywxegtxovkkxrq] has quit [Quit: Connection closed for inactivity]
18:16 -!- netsin [~jiggalato@unaffiliated/jiggalator] has quit [Remote host closed the connection]
18:24 -!- JackH [~Jack@79-73-186-51.dynamic.dsl.as9105.com] has quit [Ping timeout: 258 seconds]
18:24 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
18:31 -!- Giszmo [~leo@ppp-83-171-167-95.dynamic.mnet-online.de] has joined #bitcoin-core-dev
18:34 -!- Giszmo1 [~leo@ppp-83-171-184-80.dynamic.mnet-online.de] has quit [Ping timeout: 264 seconds]
18:40 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev
18:54 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 276 seconds]
18:54 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer]
18:54 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
18:56 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
18:56 -!- fengling_ [~fengling@58.135.95.135] has joined #bitcoin-core-dev
19:12 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Remote host closed the connection]
19:17 -!- netsin [~jiggalato@unaffiliated/jiggalator] has joined #bitcoin-core-dev
19:23 -!- netsin [~jiggalato@unaffiliated/jiggalator] has quit [Ping timeout: 240 seconds]
19:33 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 276 seconds]
19:39 -!- netsin [~jiggalato@unaffiliated/jiggalator] has joined #bitcoin-core-dev
19:41 -!- netsin [~jiggalato@unaffiliated/jiggalator] has quit [Remote host closed the connection]
19:43 -!- netsin [~jiggalato@unaffiliated/jiggalator] has joined #bitcoin-core-dev
19:44 -!- netsin [~jiggalato@unaffiliated/jiggalator] has quit [Remote host closed the connection]
19:58 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
20:01 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 250 seconds]
20:10 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
20:13 -!- netsin [~jiggalato@unaffiliated/jiggalator] has joined #bitcoin-core-dev
20:16 -!- supasonic [~supasonic@172-11-188-177.lightspeed.rcsntx.sbcglobal.net] has quit [Read error: Connection reset by peer]
20:45 -!- fengling_ [~fengling@58.135.95.135] has quit [Ping timeout: 240 seconds]
20:55 -!- fengling_ [~fengling@58.135.95.135] has joined #bitcoin-core-dev
21:02 -!- fengling_ [~fengling@58.135.95.135] has quit [Ping timeout: 240 seconds]
21:04 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit []
21:06 -!- netsin [~jiggalato@unaffiliated/jiggalator] has quit [Remote host closed the connection]
21:09 -!- netsin [~jiggalato@unaffiliated/jiggalator] has joined #bitcoin-core-dev
21:14 -!- netsin [~jiggalato@unaffiliated/jiggalator] has quit [Remote host closed the connection]
21:31 -!- netsin [~jiggalato@unaffiliated/jiggalator] has joined #bitcoin-core-dev
21:37 -!- fengling_ [~fengling@58.135.95.131] has joined #bitcoin-core-dev
21:47 -!- netsin [~jiggalato@unaffiliated/jiggalator] has quit [Remote host closed the connection]