12016-07-25T00:11:40 <Chris_Stewart_5> It seems that both values would be incorrect if I had generated the incorrect tx hash for signing..
22016-07-25T00:14:22 <sipa> you generated the k value yourself using rfc6979?
32016-07-25T00:15:13 <Chris_Stewart_5> I'm importing the key from bitcoin core's WIF format, I used dumpprivkey. Did I screw something up along the way?
42016-07-25T00:15:50 <sipa> is the overall signature valid?
52016-07-25T00:17:04 <Chris_Stewart_5> Hmm no it doesn't look so.
62016-07-25T00:19:35 <Chris_Stewart_5> Welp that at least narrows it down. I didn't realize that the r value would be correct even if the key is incorrect
72016-07-25T00:20:30 <sipa> maybe you should first try to make your code generate valid sognatures
82016-07-25T00:20:48 <sipa> before trying to mimick the signatures another implementation creates
92016-07-25T00:20:55 <sipa> *signatures
102016-07-25T00:21:19 <Chris_Stewart_5> sipa: It does generate valid signatures
112016-07-25T00:21:26 <sipa> apparently not
122016-07-25T00:22:25 <sipa> you're generating a signature that is different from the one created by bitcoin core
132016-07-25T00:22:33 <sipa> and it's not due to low-s
142016-07-25T00:22:44 <sipa> only one of both can be valid in that case
152016-07-25T00:25:10 <Chris_Stewart_5> But having the r value be correct (in accordance to bitcoin core) and the s value incorrect seems like a strange case. Any way I'm going to investigate further and play with core's signing message functionality
162016-07-25T00:25:48 *** Ylbam has quit IRC
172016-07-25T00:34:10 *** mkarrer has quit IRC
182016-07-25T00:34:18 <Chris_Stewart_5> thanks for the guidance / help
192016-07-25T00:34:54 *** mkarrer has joined #bitcoin-core-dev
202016-07-25T00:48:32 *** netsinn has joined #bitcoin-core-dev
212016-07-25T00:49:36 *** netsinn is now known as netsin_
222016-07-25T00:50:55 *** netsin_ has quit IRC
232016-07-25T00:53:17 *** netsinn has joined #bitcoin-core-dev
242016-07-25T01:00:03 *** netsinn has quit IRC
252016-07-25T01:34:39 *** netsinn has joined #bitcoin-core-dev
262016-07-25T01:39:44 *** face_ has quit IRC
272016-07-25T01:46:52 *** aalex has quit IRC
282016-07-25T01:49:01 *** Cheeseo has quit IRC
292016-07-25T01:50:22 *** aalex has joined #bitcoin-core-dev
302016-07-25T01:54:35 *** fengling has joined #bitcoin-core-dev
312016-07-25T02:02:58 *** goatpig has quit IRC
322016-07-25T02:20:04 *** netsinn has quit IRC
332016-07-25T02:20:28 *** netsinn has joined #bitcoin-core-dev
342016-07-25T02:34:21 *** netsinn has quit IRC
352016-07-25T02:56:04 *** Chris_Stewart_5 has quit IRC
362016-07-25T03:20:35 *** Chris_Stewart_5 has joined #bitcoin-core-dev
372016-07-25T03:27:41 *** Chris_Stewart_5 has quit IRC
382016-07-25T03:30:51 *** instagibbs has quit IRC
392016-07-25T04:01:35 *** instagibbs has joined #bitcoin-core-dev
402016-07-25T04:18:53 *** netsinn has joined #bitcoin-core-dev
412016-07-25T04:32:36 *** Arnavion has quit IRC
422016-07-25T04:32:41 *** Arnavion has joined #bitcoin-core-dev
432016-07-25T04:38:39 *** netsinn has quit IRC
442016-07-25T04:40:14 *** netsinn has joined #bitcoin-core-dev
452016-07-25T04:50:19 *** d_t has joined #bitcoin-core-dev
462016-07-25T04:50:32 *** adiabat has joined #bitcoin-core-dev
472016-07-25T05:00:09 *** d_t has joined #bitcoin-core-dev
482016-07-25T05:03:33 *** netsinn has quit IRC
492016-07-25T05:37:50 *** d_t has quit IRC
502016-07-25T06:00:44 *** a87ry5 has quit IRC
512016-07-25T06:30:01 *** netsinn has joined #bitcoin-core-dev
522016-07-25T06:49:21 *** BashCo has quit IRC
532016-07-25T07:10:17 *** BashCo has joined #bitcoin-core-dev
542016-07-25T07:15:14 *** frankenmint has joined #bitcoin-core-dev
552016-07-25T07:16:28 *** CubicEarth has joined #bitcoin-core-dev
562016-07-25T07:32:42 *** molz has joined #bitcoin-core-dev
572016-07-25T07:32:52 *** ratoder has joined #bitcoin-core-dev
582016-07-25T07:35:34 *** moli has quit IRC
592016-07-25T07:58:29 *** Guyver2 has joined #bitcoin-core-dev
602016-07-25T08:33:17 *** jannes has joined #bitcoin-core-dev
612016-07-25T09:29:27 *** Guyver2 has quit IRC
622016-07-25T09:30:23 *** Giszmo has joined #bitcoin-core-dev
632016-07-25T09:49:09 *** Ginnarr has joined #bitcoin-core-dev
642016-07-25T09:56:52 *** berndj has quit IRC
652016-07-25T10:00:53 *** berndj has joined #bitcoin-core-dev
662016-07-25T10:29:52 *** harrymm has quit IRC
672016-07-25T10:45:19 *** harrymm has joined #bitcoin-core-dev
682016-07-25T10:46:27 *** aalex has quit IRC
692016-07-25T10:50:19 *** AaronvanW has joined #bitcoin-core-dev
702016-07-25T10:50:27 *** aalex has joined #bitcoin-core-dev
712016-07-25T10:51:26 *** fengling has quit IRC
722016-07-25T10:51:50 <GitHub86> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0df9ea42b888...99c0ac2fd9be
732016-07-25T10:51:50 <GitHub86> bitcoin/master cc021ef lizhi: remove outdated legacy code...
742016-07-25T10:51:51 <GitHub86> bitcoin/master 99c0ac2 Wladimir J. van der Laan: Merge #8396: remove outdated legacy code from key.h...
752016-07-25T10:52:05 <GitHub85> [bitcoin] laanwj closed pull request #8396: remove outdated legacy code from key.h (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8396
762016-07-25T10:53:53 *** pedrobranco has joined #bitcoin-core-dev
772016-07-25T11:06:14 <GitHub24> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/73adfe3bb935cead8e4d91f8d1c8a9feb55e4a7d
782016-07-25T11:06:14 <GitHub24> bitcoin/0.13 73adfe3 Jonas Schnelli: [Wallet] Correct hdmasterkeyid/masterkeyid name confusion...
792016-07-25T11:08:18 *** CubicEarth has quit IRC
802016-07-25T11:24:28 *** frankenmint has quit IRC
812016-07-25T11:30:23 *** Ginnarr has quit IRC
822016-07-25T11:36:50 *** mkarrer_ has joined #bitcoin-core-dev
832016-07-25T11:40:29 *** mkarrer has quit IRC
842016-07-25T11:44:25 *** mkarrer has joined #bitcoin-core-dev
852016-07-25T11:44:25 *** mkarrer_ has quit IRC
862016-07-25T11:47:50 *** fengling has joined #bitcoin-core-dev
872016-07-25T11:52:46 *** fengling has quit IRC
882016-07-25T11:57:14 *** laurentmt has joined #bitcoin-core-dev
892016-07-25T12:02:00 *** laurentmt has quit IRC
902016-07-25T12:06:40 *** mkarrer_ has joined #bitcoin-core-dev
912016-07-25T12:08:16 *** Chris_Stewart_5 has joined #bitcoin-core-dev
922016-07-25T12:10:14 *** mkarrer has quit IRC
932016-07-25T12:14:06 *** mkarrer has joined #bitcoin-core-dev
942016-07-25T12:16:02 *** mkarrer__ has joined #bitcoin-core-dev
952016-07-25T12:17:18 *** mkarrer_ has quit IRC
962016-07-25T12:18:26 *** mkarrer_ has joined #bitcoin-core-dev
972016-07-25T12:19:51 *** mkarrer_ has quit IRC
982016-07-25T12:19:56 *** mkarrer has quit IRC
992016-07-25T12:20:23 *** mkarrer has joined #bitcoin-core-dev
1002016-07-25T12:21:31 *** mkarrer__ has quit IRC
1012016-07-25T12:26:51 <wumpus> gah happy the heatwave in NL seems to have abated a bit
1022016-07-25T12:30:02 *** cryptapus_afk is now known as cryptapus
1032016-07-25T12:45:21 *** YOU-JI has joined #bitcoin-core-dev
1042016-07-25T12:49:17 *** fengling has joined #bitcoin-core-dev
1052016-07-25T12:54:06 *** fengling has quit IRC
1062016-07-25T13:16:15 <sipa> sdaftuar: yes, that relying on extra state for cb/segwit is unfortunate... though it's restricted to the decision of what to advertize as
1072016-07-25T13:17:03 <sipa> sdaftuar: a proper solution is making it a 2-way handshake, where both nodes advertize which versions they support, and then a second message is returned to indicate which version will actually be used (potentially a different one in both directions)
1082016-07-25T13:17:10 <sdaftuar> sipa: there's also sort of an implicit behavior, where you're relying on your peer to know to only request compactblocks from you, if you're NODE_WITNESS
1092016-07-25T13:17:33 <sdaftuar> yeah that's basically what i was thinking. it's a little confusing the version number has two meanings
1102016-07-25T13:17:43 <sipa> indeed
1112016-07-25T13:17:53 <sipa> but the sendcmpct message already has two meanings as well
1122016-07-25T13:17:58 <sdaftuar> yeah
1132016-07-25T13:18:02 <sipa> 1) i can offer compact blocks
1142016-07-25T13:18:14 <sipa> 2) i want you to potentially advertize using compact blocks, if you support it
1152016-07-25T13:19:29 <sdaftuar> i guess my question is, if a peer sends you a version 2 compactblock message, and you don't support version 2 compact blocks but you do support NODE_WITNESS, what should happen?
1162016-07-25T13:19:47 <sdaftuar> i don't think there's any way to communicate to your peer that they made a mistake
1172016-07-25T13:19:58 <sipa> yes
1182016-07-25T13:20:16 <sipa> wumpus: not just in NL...
1192016-07-25T13:20:23 <sdaftuar> so at the least, we should document that explicitly.
1202016-07-25T13:20:42 <sipa> sdaftuar: now you bring it up, i feel like fixing it properly...
1212016-07-25T13:20:49 <sdaftuar> that's also my preference :)
1222016-07-25T13:20:56 * sipa hanging out with jonasschnelli
1232016-07-25T13:21:59 <sipa> sdaftuar: so, in that case, i think sendcmpct should only have the meaning "i support compact blocks version up to X"
1242016-07-25T13:22:17 <sdaftuar> and not distinguish sending/receiving?
1252016-07-25T13:22:26 <sdaftuar> i think i'd agree with that
1262016-07-25T13:22:32 <sipa> hmm, no... "i can send you version X compact blocks"
1272016-07-25T13:22:58 <sipa> and a separate version for asking the peer to actually do that
1282016-07-25T13:24:19 <sdaftuar> why not just assume that the two peers will send/receive at the highest version they both support? i was thinking the peer who supports the higher version will advertise at the lower version to complete the handshake
1292016-07-25T13:25:44 <sipa> well the protocol is not necessarily symmetric
1302016-07-25T13:26:07 <sipa> one side may want inv using cmpctblock
1312016-07-25T13:26:10 <sipa> while the other does not
1322016-07-25T13:26:32 <sdaftuar> well we have the separate announcements bool inside the message
1332016-07-25T13:26:48 <sipa> BlueMatt: ping ^
1342016-07-25T13:26:51 <sdaftuar> i just figure that the chances that you are able to announce a compactblock with wtxid's, but prefer compactblock announcements using txid's, is an unsupported use case
1352016-07-25T13:27:07 <sdaftuar> prefer receiving*
1362016-07-25T13:29:27 <sdaftuar> so my proposed protocol flow would be: you send me SENDCMPCT(announce=whatever, version=2). i send you SENDCMPCT(announce=whatever, version=1). you send me SENDCMPCT(announce=false, version=1).
1372016-07-25T13:29:43 <sdaftuar> (i have to ignore your first SENDCMPCT because it's too high version and i don't support it, as per the BIP)
1382016-07-25T13:30:07 <sipa> who sends first?
1392016-07-25T13:30:09 *** Chris_Stewart_5 has quit IRC
1402016-07-25T13:30:19 <sdaftuar> i don't think it matters, except that if you got mine first, you wouldn't bother sending a version=2 message
1412016-07-25T13:30:43 <sipa> i find protocols that try to negotiate things for both directions hard to reason about
1422016-07-25T13:31:20 <sdaftuar> i'm not sure it matters that announcements are a different direction than decoding, since we can just assume that if you can encode, you can decode, right?
1432016-07-25T13:31:22 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1442016-07-25T13:31:56 <sdaftuar> that's not strictly true of course, but just seems like not something we'd need to support
1452016-07-25T13:31:56 <sipa> well a segwit node with wtxid-based table can encode compact blocks with txids or wtxids, but only decide wtxid based ones
1462016-07-25T13:32:07 <sipa> s/decide/decode/
1472016-07-25T13:32:46 <sdaftuar> fair point
1482016-07-25T13:35:00 <sdaftuar> in this situation it's the opposite case that would be the concern, ie if you're capable of encoding with wtxid's or txid's, but are only able to decode txid-based ones
1492016-07-25T13:35:18 <sdaftuar> because in your example, you'd just never request compactblocks from the version1 peer
1502016-07-25T13:35:40 <sdaftuar> by using announce=false, and not requesting compact blocks otherwise
1512016-07-25T13:41:59 <sipa> right
1522016-07-25T13:44:28 *** mkarrer_ has joined #bitcoin-core-dev
1532016-07-25T13:44:57 *** YOU-JI_ has joined #bitcoin-core-dev
1542016-07-25T13:45:54 *** YOU-JI has quit IRC
1552016-07-25T13:47:04 *** mkarrer has quit IRC
1562016-07-25T13:51:14 *** fengling has joined #bitcoin-core-dev
1572016-07-25T13:56:06 *** fengling has quit IRC
1582016-07-25T13:58:23 *** frankenmint has joined #bitcoin-core-dev
1592016-07-25T13:58:47 *** arubi_ has joined #bitcoin-core-dev
1602016-07-25T13:59:59 *** pedrobranco has quit IRC
1612016-07-25T14:00:09 *** pedrobranco has joined #bitcoin-core-dev
1622016-07-25T14:01:11 *** YOU-JI_ has quit IRC
1632016-07-25T14:02:00 *** arubi has quit IRC
1642016-07-25T14:02:55 *** TomMc has joined #bitcoin-core-dev
1652016-07-25T14:08:05 *** Chris_Stewart_5 has quit IRC
1662016-07-25T14:24:21 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1672016-07-25T14:42:07 *** jl2012 has quit IRC
1682016-07-25T14:42:29 *** jl2012 has joined #bitcoin-core-dev
1692016-07-25T14:48:37 *** zooko has joined #bitcoin-core-dev
1702016-07-25T14:51:29 *** arubi__ has joined #bitcoin-core-dev
1712016-07-25T14:53:11 *** fengling has joined #bitcoin-core-dev
1722016-07-25T14:54:37 *** frankenmint has quit IRC
1732016-07-25T14:54:51 *** arubi_ has quit IRC
1742016-07-25T14:58:06 *** fengling has quit IRC
1752016-07-25T15:06:31 *** laurentmt has joined #bitcoin-core-dev
1762016-07-25T15:11:19 *** laurentmt has quit IRC
1772016-07-25T15:14:17 *** Giszmo has quit IRC
1782016-07-25T15:27:49 <GitHub84> [bitcoin] rebroad opened pull request #8403: Process "notfound" messages, and safeguard against unreasonably long ⦠(master...ProcessNotfound) https://github.com/bitcoin/bitcoin/pull/8403
1792016-07-25T15:31:10 *** Ylbam has joined #bitcoin-core-dev
1802016-07-25T15:37:18 *** BashCo has quit IRC
1812016-07-25T15:37:27 *** pedrobranco has quit IRC
1822016-07-25T15:38:00 *** pedrobranco has joined #bitcoin-core-dev
1832016-07-25T15:45:42 *** pedrobranco has quit IRC
1842016-07-25T15:45:50 *** pedrobranco has joined #bitcoin-core-dev
1852016-07-25T15:54:45 *** fengling has joined #bitcoin-core-dev
1862016-07-25T15:56:21 *** Chris_Stewart_5 has quit IRC
1872016-07-25T15:58:41 *** BashCo has joined #bitcoin-core-dev
1882016-07-25T15:59:26 *** fengling has quit IRC
1892016-07-25T16:08:33 <GitHub43> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/99c0ac2fd9be...517eee3e8f8b
1902016-07-25T16:08:34 <GitHub43> bitcoin/master 682aa0f Suhas Daftuar: Scale legacy sigop count in CreateNewBlock
1912016-07-25T16:08:34 <GitHub43> bitcoin/master 517eee3 Wladimir J. van der Laan: Merge #8362: Scale legacy sigop count in CreateNewBlock...
1922016-07-25T16:08:43 <GitHub191> [bitcoin] laanwj closed pull request #8362: Scale legacy sigop count in CreateNewBlock (master...coinbase-sigops-scale) https://github.com/bitcoin/bitcoin/pull/8362
1932016-07-25T16:09:56 <GitHub149> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/86edc20a178cc17cdc6915e9e93a7241c27c368c
1942016-07-25T16:09:56 <GitHub149> bitcoin/0.13 86edc20 Suhas Daftuar: Scale legacy sigop count in CreateNewBlock...
1952016-07-25T16:13:11 *** pedrobranco has quit IRC
1962016-07-25T16:13:17 *** pedrobranco has joined #bitcoin-core-dev
1972016-07-25T16:22:37 *** jtimon has joined #bitcoin-core-dev
1982016-07-25T16:34:01 *** arubi__ is now known as arubi
1992016-07-25T16:36:35 *** anu0 has joined #bitcoin-core-dev
2002016-07-25T16:56:15 *** fengling has joined #bitcoin-core-dev
2012016-07-25T16:58:00 *** zooko has quit IRC
2022016-07-25T16:58:33 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2032016-07-25T17:00:28 *** DongSwanson has joined #bitcoin-core-dev
2042016-07-25T17:01:06 *** fengling has quit IRC
2052016-07-25T17:01:52 *** arubi_ has joined #bitcoin-core-dev
2062016-07-25T17:03:57 *** arubi has quit IRC
2072016-07-25T17:03:59 *** arubi_ is now known as arubi
2082016-07-25T17:04:06 <DongSwanson> can somebody help me with utilizing CHECKSEQUENCEVERIFY with bitcoin-core? I want to create a "escrow with timeout" with bitcoin-core
2092016-07-25T17:04:11 *** d_t has joined #bitcoin-core-dev
2102016-07-25T17:20:34 <jl2012> DongSwanson: I think you can only do it manually. Try on the testnet first
2112016-07-25T17:21:51 <DongSwanson> jl2012: what do you mean by manually?
2122016-07-25T17:23:31 *** Chris_Stewart_5 has quit IRC
2132016-07-25T17:24:51 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2142016-07-25T17:27:24 <sipa> DongSwanson: the wallet code can't sign such transactions
2152016-07-25T17:27:37 <sipa> so you'll need to construct the scriptSig using other tools
2162016-07-25T17:27:42 *** pedrobranco has quit IRC
2172016-07-25T17:28:09 *** pedrobranco has joined #bitcoin-core-dev
2182016-07-25T17:29:03 <DongSwanson> sipa: oh. so if I wanted to create a escrow with timeout for a real world scenario, we cannot use bitcoin-core?
2192016-07-25T17:31:03 *** spudowiar has quit IRC
2202016-07-25T17:32:52 *** pedrobranco has quit IRC
2212016-07-25T17:34:19 <sipa> DongSwanson: you can't use its wallet code for constructing such transactions
2222016-07-25T17:34:19 <Chris_Stewart_5> DongSwanson: Bitcoin Core doesn't expose functionality to create custom contracts through a user interface (that I know of...) You need to manually construct the contract
2232016-07-25T17:34:52 <sipa> manually construct the contract (the easy part) and manually satisfy the contract (the hard part...)
2242016-07-25T17:34:59 <gmaxwell> Creating it is not a big deal, but without a way to sign for it you will burn your funds.
2252016-07-25T17:35:19 <Chris_Stewart_5> You can use something like peter todd's python bitcoin library or whatever library there is for your favorite language
2262016-07-25T17:35:52 <sipa> or you can help review pull request 7601
2272016-07-25T17:36:00 <Chris_Stewart_5> as sipa and gmaxwell said, best to experiment on testnet/regtest
2282016-07-25T17:36:14 <sipa> which adds support for HTLC's (contracts which have a timelock and a hashlock)
2292016-07-25T17:37:06 <Chris_Stewart_5> through bitcoin core's wallet UI?
2302016-07-25T17:37:45 <JackH> there is a pull request for wallet features that enables "smarter" functions?
2312016-07-25T17:38:47 <DongSwanson> so bitcoin-core cannot create CSV escrows but can sign it's outgoing transactions if you provide the correct redeemscript?
2322016-07-25T17:38:57 <sipa> DongSwanson: nope
2332016-07-25T17:39:03 <sipa> the other way around
2342016-07-25T17:39:08 <DongSwanson> it cannot sign as well?
2352016-07-25T17:39:16 <JackH> found it: https://github.com/bitcoin/bitcoin/pull/7601
2362016-07-25T17:39:20 <DongSwanson> okay. i understand
2372016-07-25T17:39:23 <JackH> why are you guys keeping all these gems for yourself
2382016-07-25T17:39:32 <sipa> it can create outputs to csv scripts
2392016-07-25T17:39:38 <sipa> but it can't spend them
2402016-07-25T17:40:25 <sipa> JackH: how do you mean to ourself?
2412016-07-25T17:40:30 <Chris_Stewart_5> sipa: Even if you construct the inputs for the contract correctly, it won't be propogated will it?
2422016-07-25T17:40:43 <JackH> I was joking because I didnt know about this myself
2432016-07-25T17:40:46 <JackH> I know its public ;)
2442016-07-25T17:40:50 <sipa> ha ok
2452016-07-25T17:40:59 <sipa> Chris_Stewart_5: it's standard
2462016-07-25T17:41:14 <JackH> I always wanted a core wallet with a bit more options unlocked, as we have nothing like that
2472016-07-25T17:41:39 <Chris_Stewart_5> Hmm for some reason I thought redeem scripts needed to be standard scriptPubKey
2482016-07-25T17:41:40 <JackH> probably both good and bad as you wouldn have to answer support questions on IRC all day about how people can get their 10 year time locked Bitcoins back
2492016-07-25T17:42:08 *** netsinn has joined #bitcoin-core-dev
2502016-07-25T17:42:30 <sipa> Chris_Stewart_5: not anymore since a few releases
2512016-07-25T17:44:31 <sipa> JackH: well CSV only activated a few weeks ago
2522016-07-25T17:45:31 <JackH> yeah I can see in the pull maxwell says he will take a look at it after segwit
2532016-07-25T17:45:50 <DongSwanson> so I guess I'll give it some more time
2542016-07-25T17:48:58 <DongSwanson> thanks everybody for your input. I'll ask again in a few weeks. Be prepared :-)
2552016-07-25T17:49:52 <sipa> DongSwanson: you can help make things move forward by testing the HTLC pull request, for example
2562016-07-25T17:50:04 <sipa> waiting may work, helping gets you further
2572016-07-25T17:53:21 <DongSwanson> good idea. Bitcoin has given me a lot. Maybe it is time to give something back. I'll look into that tomorrow.
2582016-07-25T17:53:59 *** Chris_Stewart_5 has quit IRC
2592016-07-25T17:57:43 *** fengling has joined #bitcoin-core-dev
2602016-07-25T18:02:26 *** fengling has quit IRC
2612016-07-25T18:09:59 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2622016-07-25T18:15:50 *** spudowiar has joined #bitcoin-core-dev
2632016-07-25T18:18:25 *** laurentmt has joined #bitcoin-core-dev
2642016-07-25T18:21:24 *** BitcoinErrorLog has joined #bitcoin-core-dev
2652016-07-25T18:22:42 *** netsinn has quit IRC
2662016-07-25T18:26:46 *** Chris_Stewart_5 has quit IRC
2672016-07-25T18:28:58 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2682016-07-25T18:29:21 *** netsinn has joined #bitcoin-core-dev
2692016-07-25T18:59:31 *** fengling has joined #bitcoin-core-dev
2702016-07-25T19:04:26 *** fengling has quit IRC
2712016-07-25T19:10:25 *** Lauda has quit IRC
2722016-07-25T19:12:48 *** laurentmt has quit IRC
2732016-07-25T19:13:06 *** laurentmt has joined #bitcoin-core-dev
2742016-07-25T19:14:20 *** Lauda has joined #bitcoin-core-dev
2752016-07-25T19:17:25 *** BitcoinErrorLog has quit IRC
2762016-07-25T19:40:40 *** pedrobranco has joined #bitcoin-core-dev
2772016-07-25T19:44:01 *** Guyver2 has joined #bitcoin-core-dev
2782016-07-25T19:44:42 *** pedrobranco has quit IRC
2792016-07-25T19:55:52 *** Chris_Stewart_5 has quit IRC
2802016-07-25T20:00:46 *** fengling has joined #bitcoin-core-dev
2812016-07-25T20:03:30 *** laurentmt has quit IRC
2822016-07-25T20:04:05 *** anu1 has joined #bitcoin-core-dev
2832016-07-25T20:04:10 *** laurentmt has joined #bitcoin-core-dev
2842016-07-25T20:05:24 *** laurentmt has quit IRC
2852016-07-25T20:05:26 *** fengling has quit IRC
2862016-07-25T20:07:40 *** anu0 has quit IRC
2872016-07-25T20:23:47 *** menix01 has joined #bitcoin-core-dev
2882016-07-25T20:24:20 <menix01> anyboady talck here?
2892016-07-25T20:24:54 <sipa> nope, never
2902016-07-25T20:25:00 <btcdrak> I can confirm
2912016-07-25T20:29:00 <menix01> and why you stay here peoples
2922016-07-25T20:29:17 <sipa> to discuss the development of the software project called Bitcoin Core
2932016-07-25T20:29:20 <sipa> see the topic
2942016-07-25T20:29:37 <menix01> i see but u say noboady speack
2952016-07-25T20:29:44 <menix01> that why\m comfuse
2962016-07-25T20:30:25 <sipa> well, us saying that nobody says something is a clearly self-defeating statement
2972016-07-25T20:30:29 <sipa> so perhaps it is a joke?
2982016-07-25T20:30:51 <menix01> ok i was pm u private sipa
2992016-07-25T20:31:17 <sipa> sorry, not interested
3002016-07-25T20:31:32 <menix01> ok
3012016-07-25T20:37:37 *** cryptapus is now known as cryptapus_afk
3022016-07-25T20:44:31 <PatBoy> thx for ur great work dev :)
3032016-07-25T20:48:01 *** jannes has quit IRC
3042016-07-25T20:54:31 *** Lauda has quit IRC
3052016-07-25T20:57:30 *** Lauda has joined #bitcoin-core-dev
3062016-07-25T21:01:46 *** fengling has joined #bitcoin-core-dev
3072016-07-25T21:06:26 *** fengling has quit IRC
3082016-07-25T21:20:16 *** LaudaM has joined #bitcoin-core-dev
3092016-07-25T21:21:58 *** Lauda has quit IRC
3102016-07-25T21:22:02 *** LaudaM is now known as Lauda
3112016-07-25T21:35:00 *** TomMc has quit IRC
3122016-07-25T21:47:43 *** spudowiar has quit IRC
3132016-07-25T21:47:59 *** TomMc has joined #bitcoin-core-dev
3142016-07-25T21:49:25 *** spudowiar has joined #bitcoin-core-dev
3152016-07-25T21:56:32 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3162016-07-25T22:02:32 *** cryptapus has joined #bitcoin-core-dev
3172016-07-25T22:03:16 *** fengling has joined #bitcoin-core-dev
3182016-07-25T22:08:06 *** fengling has quit IRC
3192016-07-25T22:11:57 *** cryptapus has quit IRC
3202016-07-25T22:14:25 *** davec has quit IRC
3212016-07-25T22:15:20 *** davec has joined #bitcoin-core-dev
3222016-07-25T22:17:42 *** jtimon has quit IRC
3232016-07-25T22:18:36 *** netsinn has quit IRC
3242016-07-25T22:25:06 *** spudowiar has quit IRC
3252016-07-25T22:26:23 *** spudowiar has joined #bitcoin-core-dev
3262016-07-25T22:28:34 *** harrymm has quit IRC
3272016-07-25T22:31:10 *** netsinn has joined #bitcoin-core-dev
3282016-07-25T22:43:32 <BlueMatt> sdaftuar: sipa sorry, whats up?
3292016-07-25T22:46:29 <BlueMatt> I was figuring if you're getting witnesses in blocks, and a peer doesnt support receiving witnesses over cmpctblocks, you just send them full blocks
3302016-07-25T22:47:06 <BlueMatt> like, backward compat there is not hugely important to me?
3312016-07-25T22:49:41 *** harrymm has joined #bitcoin-core-dev
3322016-07-25T23:04:43 *** fengling has joined #bitcoin-core-dev
3332016-07-25T23:05:16 *** spudowiar has quit IRC
3342016-07-25T23:07:27 *** spudowiar1 has joined #bitcoin-core-dev
3352016-07-25T23:07:55 *** spudowiar1 is now known as spudowiar
3362016-07-25T23:09:26 *** fengling has quit IRC
3372016-07-25T23:11:17 <sipa> BlueMatt: brb in 5 minutes
3382016-07-25T23:12:30 *** aalex has quit IRC
3392016-07-25T23:14:08 <sipa> BlueMatt: i think the first question is more general about how to deal with multiple versions cmpctblocks
3402016-07-25T23:14:22 <sipa> BlueMatt: because there is no way to negotiate
3412016-07-25T23:14:56 <BlueMatt> hmm, I had a scheme in mind when I wrote it.....
3422016-07-25T23:14:58 <BlueMatt> lemme go look
3432016-07-25T23:15:23 *** aalex has joined #bitcoin-core-dev
3442016-07-25T23:18:41 *** ryan-c has joined #bitcoin-core-dev
3452016-07-25T23:22:41 *** adiabat has quit IRC
3462016-07-25T23:23:18 *** ryan-c has quit IRC
3472016-07-25T23:26:10 *** Guyver2 has quit IRC
3482016-07-25T23:29:22 <BlueMatt> ahh, yea, in the `sendcmpct` section: "Upon receipt of a "sendcmpct" message with the second integer set to something other than 1, nodes MUST treat the peer as if they had not received the message (as it indicates the peer will provide an unexpected encoding in cmpctblock, and/or other, messages). This allows future versions to send duplicate sendcmpct messages with different versions as a part of a version handshake for future versio
3492016-07-25T23:29:23 <BlueMatt> ns."
3502016-07-25T23:29:49 <sipa> BlueMatt: aha!
3512016-07-25T23:30:04 <sipa> that sounds interesting
3522016-07-25T23:30:24 <BlueMatt> intention was that, if you support version 2, you can just send 2 sendcmpct messages
3532016-07-25T23:30:28 <BlueMatt> 1 with version 1, one with version 2
3542016-07-25T23:30:37 <sipa> i'll adapt bip and pr
3552016-07-25T23:30:45 <sipa> actually, only pr
3562016-07-25T23:30:47 <gmaxwell> also means you can stop supporting v1 at some point.
3572016-07-25T23:31:06 <sipa> indeed
3582016-07-25T23:31:21 *** frankenmint has joined #bitcoin-core-dev
3592016-07-25T23:31:29 <sipa> code now decides what to send based on whether the peer sets node_witness
3602016-07-25T23:31:34 <BlueMatt> sipa: if you want, you could pull that out and put it elsewhere in the bip...its kinda easy to miss as a bullet in a seemingly-unrelated section :p
3612016-07-25T23:31:39 <sipa> but we shoukd just send both
3622016-07-25T23:31:48 <sipa> and let the receiver decide
3632016-07-25T23:31:56 <BlueMatt> yea, I was thinking do cmpctblockversion = max(all received sendcmpctblock messages)
3642016-07-25T23:32:00 <sipa> *should
3652016-07-25T23:32:02 <BlueMatt> but...whatever
3662016-07-25T23:37:28 *** frankenmint has quit IRC
3672016-07-25T23:44:33 *** frankenmint has joined #bitcoin-core-dev
3682016-07-25T23:57:30 <luke-jr> so.. not having a solution to the GBT weightlimit issue.. is it correct that the weight of a gen tx is always (size * 4) + (1 byte for witness stack size + 1 byte for stack item size + 32 bytes stack item nonce) = (size*4)+34 ?
3692016-07-25T23:57:38 <luke-jr> sipa: ^