1 2016-07-25 00:11:41 0|Chris_Stewart_5|It seems that both values would be incorrect if I had generated the incorrect tx hash for signing..
2 2016-07-25 00:14:22 0|sipa|you generated the k value yourself using rfc6979?
3 2016-07-25 00:15:14 0|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?
4 2016-07-25 00:15:50 0|sipa|is the overall signature valid?
5 2016-07-25 00:17:04 0|Chris_Stewart_5|Hmm no it doesn't look so.
6 2016-07-25 00:19:35 0|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
7 2016-07-25 00:20:31 0|sipa|maybe you should first try to make your code generate valid sognatures
8 2016-07-25 00:20:48 0|sipa|before trying to mimick the signatures another implementation creates
9 2016-07-25 00:20:56 0|sipa|*signatures
10 2016-07-25 00:21:19 0|Chris_Stewart_5|sipa: It does generate valid signatures
11 2016-07-25 00:21:26 0|sipa|apparently not
12 2016-07-25 00:22:25 0|sipa|you're generating a signature that is different from the one created by bitcoin core
13 2016-07-25 00:22:34 0|sipa|and it's not due to low-s
14 2016-07-25 00:22:44 0|sipa|only one of both can be valid in that case
15 2016-07-25 00:25:10 0|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
16 2016-07-25 00:34:18 0|Chris_Stewart_5|thanks for the guidance / help
17 2016-07-25 10:51:51 0|GitHub86|13bitcoin/06master 14cc021ef 15lizhi: remove outdated legacy code...
18 2016-07-25 10:51:51 0|GitHub86|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/0df9ea42b888...99c0ac2fd9be
19 2016-07-25 10:51:52 0|GitHub86|13bitcoin/06master 1499c0ac2 15Wladimir J. van der Laan: Merge #8396: remove outdated legacy code from key.h...
20 2016-07-25 10:52:06 0|GitHub85|[13bitcoin] 15laanwj closed pull request #8396: remove outdated legacy code from key.h (06master...06patch-1) 02 https://github.com/bitcoin/bitcoin/pull/8396
21 2016-07-25 11:06:14 0|GitHub24|13bitcoin/060.13 1473adfe3 15Jonas Schnelli: [Wallet] Correct hdmasterkeyid/masterkeyid name confusion...
22 2016-07-25 11:06:14 0|GitHub24|[13bitcoin] 15laanwj pushed 1 new commit to 060.13: 02 https://github.com/bitcoin/bitcoin/commit/73adfe3bb935cead8e4d91f8d1c8a9feb55e4a7d
23 2016-07-25 12:26:51 0|wumpus|gah happy the heatwave in NL seems to have abated a bit
24 2016-07-25 13:16:15 0|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
25 2016-07-25 13:17:04 0|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)
26 2016-07-25 13:17:11 0|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
27 2016-07-25 13:17:33 0|sdaftuar|yeah that's basically what i was thinking. it's a little confusing the version number has two meanings
28 2016-07-25 13:17:43 0|sipa|indeed
29 2016-07-25 13:17:54 0|sipa|but the sendcmpct message already has two meanings as well
30 2016-07-25 13:17:58 0|sdaftuar|yeah
31 2016-07-25 13:18:02 0|sipa|1) i can offer compact blocks
32 2016-07-25 13:18:15 0|sipa|2) i want you to potentially advertize using compact blocks, if you support it
33 2016-07-25 13:19:29 0|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?
34 2016-07-25 13:19:47 0|sdaftuar|i don't think there's any way to communicate to your peer that they made a mistake
35 2016-07-25 13:19:59 0|sipa|yes
36 2016-07-25 13:20:17 0|sipa|wumpus: not just in NL...
37 2016-07-25 13:20:24 0|sdaftuar|so at the least, we should document that explicitly.
38 2016-07-25 13:20:42 0|sipa|sdaftuar: now you bring it up, i feel like fixing it properly...
39 2016-07-25 13:20:49 0|sdaftuar|that's also my preference :)
40 2016-07-25 13:22:00 0|sipa|sdaftuar: so, in that case, i think sendcmpct should only have the meaning "i support compact blocks version up to X"
41 2016-07-25 13:22:17 0|sdaftuar|and not distinguish sending/receiving?
42 2016-07-25 13:22:26 0|sdaftuar|i think i'd agree with that
43 2016-07-25 13:22:32 0|sipa|hmm, no... "i can send you version X compact blocks"
44 2016-07-25 13:22:58 0|sipa|and a separate version for asking the peer to actually do that
45 2016-07-25 13:24:19 0|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
46 2016-07-25 13:25:44 0|sipa|well the protocol is not necessarily symmetric
47 2016-07-25 13:26:07 0|sipa|one side may want inv using cmpctblock
48 2016-07-25 13:26:10 0|sipa|while the other does not
49 2016-07-25 13:26:32 0|sdaftuar|well we have the separate announcements bool inside the message
50 2016-07-25 13:26:49 0|sipa|BlueMatt: ping ^
51 2016-07-25 13:26:52 0|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
52 2016-07-25 13:27:07 0|sdaftuar|prefer receiving*
53 2016-07-25 13:29:28 0|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).
54 2016-07-25 13:29:43 0|sdaftuar|(i have to ignore your first SENDCMPCT because it's too high version and i don't support it, as per the BIP)
55 2016-07-25 13:30:08 0|sipa|who sends first?
56 2016-07-25 13:30:19 0|sdaftuar|i don't think it matters, except that if you got mine first, you wouldn't bother sending a version=2 message
57 2016-07-25 13:30:43 0|sipa|i find protocols that try to negotiate things for both directions hard to reason about
58 2016-07-25 13:31:20 0|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?
59 2016-07-25 13:31:56 0|sdaftuar|that's not strictly true of course, but just seems like not something we'd need to support
60 2016-07-25 13:31:56 0|sipa|well a segwit node with wtxid-based table can encode compact blocks with txids or wtxids, but only decide wtxid based ones
61 2016-07-25 13:32:07 0|sipa|s/decide/decode/
62 2016-07-25 13:32:46 0|sdaftuar|fair point
63 2016-07-25 13:35:01 0|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
64 2016-07-25 13:35:18 0|sdaftuar|because in your example, you'd just never request compactblocks from the version1 peer
65 2016-07-25 13:35:40 0|sdaftuar|by using announce=false, and not requesting compact blocks otherwise
66 2016-07-25 13:41:59 0|sipa|right
67 2016-07-25 15:27:49 0|GitHub84|[13bitcoin] 15rebroad opened pull request #8403: Process "notfound" messages, and safeguard against unreasonably long ââ¬Â¦ (06master...06ProcessNotfound) 02 https://github.com/bitcoin/bitcoin/pull/8403
68 2016-07-25 16:08:34 0|GitHub43|13bitcoin/06master 14682aa0f 15Suhas Daftuar: Scale legacy sigop count in CreateNewBlock
69 2016-07-25 16:08:34 0|GitHub43|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/99c0ac2fd9be...517eee3e8f8b
70 2016-07-25 16:08:35 0|GitHub43|13bitcoin/06master 14517eee3 15Wladimir J. van der Laan: Merge #8362: Scale legacy sigop count in CreateNewBlock...
71 2016-07-25 16:08:44 0|GitHub191|[13bitcoin] 15laanwj closed pull request #8362: Scale legacy sigop count in CreateNewBlock (06master...06coinbase-sigops-scale) 02 https://github.com/bitcoin/bitcoin/pull/8362
72 2016-07-25 16:09:57 0|GitHub149|13bitcoin/060.13 1486edc20 15Suhas Daftuar: Scale legacy sigop count in CreateNewBlock...
73 2016-07-25 16:09:57 0|GitHub149|[13bitcoin] 15laanwj pushed 1 new commit to 060.13: 02 https://github.com/bitcoin/bitcoin/commit/86edc20a178cc17cdc6915e9e93a7241c27c368c
74 2016-07-25 17:04:07 0|DongSwanson|can somebody help me with utilizing CHECKSEQUENCEVERIFY with bitcoin-core? I want to create a "escrow with timeout" with bitcoin-core
75 2016-07-25 17:20:34 0|jl2012|DongSwanson: I think you can only do it manually. Try on the testnet first
76 2016-07-25 17:21:52 0|DongSwanson|jl2012: what do you mean by manually?
77 2016-07-25 17:27:24 0|sipa|DongSwanson: the wallet code can't sign such transactions
78 2016-07-25 17:27:37 0|sipa|so you'll need to construct the scriptSig using other tools
79 2016-07-25 17:29:04 0|DongSwanson|sipa: oh. so if I wanted to create a escrow with timeout for a real world scenario, we cannot use bitcoin-core?
80 2016-07-25 17:34:19 0|sipa|DongSwanson: you can't use its wallet code for constructing such transactions
81 2016-07-25 17:34:20 0|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
82 2016-07-25 17:34:52 0|sipa|manually construct the contract (the easy part) and manually satisfy the contract (the hard part...)
83 2016-07-25 17:35:00 0|gmaxwell|Creating it is not a big deal, but without a way to sign for it you will burn your funds.
84 2016-07-25 17:35:19 0|Chris_Stewart_5|You can use something like peter todd's python bitcoin library or whatever library there is for your favorite language
85 2016-07-25 17:35:53 0|sipa|or you can help review pull request 7601
86 2016-07-25 17:36:01 0|Chris_Stewart_5|as sipa and gmaxwell said, best to experiment on testnet/regtest
87 2016-07-25 17:36:14 0|sipa|which adds support for HTLC's (contracts which have a timelock and a hashlock)
88 2016-07-25 17:37:07 0|Chris_Stewart_5|through bitcoin core's wallet UI?
89 2016-07-25 17:37:46 0|JackH|there is a pull request for wallet features that enables "smarter" functions?
90 2016-07-25 17:38:47 0|DongSwanson|so bitcoin-core cannot create CSV escrows but can sign it's outgoing transactions if you provide the correct redeemscript?
91 2016-07-25 17:38:57 0|sipa|DongSwanson: nope
92 2016-07-25 17:39:03 0|sipa|the other way around
93 2016-07-25 17:39:08 0|DongSwanson|it cannot sign as well?
94 2016-07-25 17:39:16 0|JackH|found it: https://github.com/bitcoin/bitcoin/pull/7601
95 2016-07-25 17:39:20 0|DongSwanson|okay. i understand
96 2016-07-25 17:39:23 0|JackH|why are you guys keeping all these gems for yourself
97 2016-07-25 17:39:33 0|sipa|it can create outputs to csv scripts
98 2016-07-25 17:39:39 0|sipa|but it can't spend them
99 2016-07-25 17:40:26 0|sipa|JackH: how do you mean to ourself?
100 2016-07-25 17:40:30 0|Chris_Stewart_5|sipa: Even if you construct the inputs for the contract correctly, it won't be propogated will it?
101 2016-07-25 17:40:44 0|JackH|I was joking because I didnt know about this myself
102 2016-07-25 17:40:46 0|JackH|I know its public ;)
103 2016-07-25 17:40:51 0|sipa|ha ok
104 2016-07-25 17:40:59 0|sipa|Chris_Stewart_5: it's standard
105 2016-07-25 17:41:14 0|JackH|I always wanted a core wallet with a bit more options unlocked, as we have nothing like that
106 2016-07-25 17:41:39 0|Chris_Stewart_5|Hmm for some reason I thought redeem scripts needed to be standard scriptPubKey
107 2016-07-25 17:41:41 0|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
108 2016-07-25 17:42:30 0|sipa|Chris_Stewart_5: not anymore since a few releases
109 2016-07-25 17:44:32 0|sipa|JackH: well CSV only activated a few weeks ago
110 2016-07-25 17:45:31 0|JackH|yeah I can see in the pull maxwell says he will take a look at it after segwit
111 2016-07-25 17:45:51 0|DongSwanson|so I guess I'll give it some more time
112 2016-07-25 17:48:58 0|DongSwanson|thanks everybody for your input. I'll ask again in a few weeks. Be prepared :-)
113 2016-07-25 17:49:52 0|sipa|DongSwanson: you can help make things move forward by testing the HTLC pull request, for example
114 2016-07-25 17:50:05 0|sipa|waiting may work, helping gets you further
115 2016-07-25 17:53:22 0|DongSwanson|good idea. Bitcoin has given me a lot. Maybe it is time to give something back. I'll look into that tomorrow.
116 2016-07-25 20:24:20 0|menix01|anyboady talck here?
117 2016-07-25 20:24:54 0|sipa|nope, never
118 2016-07-25 20:25:00 0|btcdrak|I can confirm
119 2016-07-25 20:29:00 0|menix01|and why you stay here peoples
120 2016-07-25 20:29:18 0|sipa|to discuss the development of the software project called Bitcoin Core
121 2016-07-25 20:29:21 0|sipa|see the topic
122 2016-07-25 20:29:38 0|menix01|i see but u say noboady speack
123 2016-07-25 20:29:45 0|menix01|that why\m comfuse
124 2016-07-25 20:30:26 0|sipa|well, us saying that nobody says something is a clearly self-defeating statement
125 2016-07-25 20:30:29 0|sipa|so perhaps it is a joke?
126 2016-07-25 20:30:52 0|menix01|ok i was pm u private sipa
127 2016-07-25 20:31:17 0|sipa|sorry, not interested
128 2016-07-25 20:31:32 0|menix01|ok
129 2016-07-25 20:44:31 0|PatBoy|thx for ur great work dev :)
130 2016-07-25 22:43:33 0|BlueMatt|sdaftuar: sipa sorry, whats up?
131 2016-07-25 22:46:29 0|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
132 2016-07-25 22:47:07 0|BlueMatt|like, backward compat there is not hugely important to me?
133 2016-07-25 23:11:17 0|sipa|BlueMatt: brb in 5 minutes
134 2016-07-25 23:14:09 0|sipa|BlueMatt: i think the first question is more general about how to deal with multiple versions cmpctblocks
135 2016-07-25 23:14:22 0|sipa|BlueMatt: because there is no way to negotiate
136 2016-07-25 23:14:57 0|BlueMatt|hmm, I had a scheme in mind when I wrote it.....
137 2016-07-25 23:14:58 0|BlueMatt|lemme go look
138 2016-07-25 23:29:23 0|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
139 2016-07-25 23:29:23 0|BlueMatt|ns."
140 2016-07-25 23:29:50 0|sipa|BlueMatt: aha!
141 2016-07-25 23:30:04 0|sipa|that sounds interesting
142 2016-07-25 23:30:25 0|BlueMatt|intention was that, if you support version 2, you can just send 2 sendcmpct messages
143 2016-07-25 23:30:29 0|BlueMatt|1 with version 1, one with version 2
144 2016-07-25 23:30:37 0|sipa|i'll adapt bip and pr
145 2016-07-25 23:30:46 0|sipa|actually, only pr
146 2016-07-25 23:30:48 0|gmaxwell|also means you can stop supporting v1 at some point.
147 2016-07-25 23:31:07 0|sipa|indeed
148 2016-07-25 23:31:30 0|sipa|code now decides what to send based on whether the peer sets node_witness
149 2016-07-25 23:31:34 0|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
150 2016-07-25 23:31:39 0|sipa|but we shoukd just send both
151 2016-07-25 23:31:48 0|sipa|and let the receiver decide
152 2016-07-25 23:31:57 0|BlueMatt|yea, I was thinking do cmpctblockversion = max(all received sendcmpctblock messages)
153 2016-07-25 23:32:00 0|sipa|*should
154 2016-07-25 23:32:03 0|BlueMatt|but...whatever
155 2016-07-25 23:57:30 0|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 ?
156 2016-07-25 23:57:38 0|luke-jr|sipa: ^