< Chris_Stewart_5>
It seems that both values would be incorrect if I had generated the incorrect tx hash for signing..
< sipa>
you generated the k value yourself using rfc6979?
< 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?
< sipa>
is the overall signature valid?
< Chris_Stewart_5>
Hmm no it doesn't look so.
< 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
< sipa>
maybe you should first try to make your code generate valid sognatures
< sipa>
before trying to mimick the signatures another implementation creates
< sipa>
*signatures
< Chris_Stewart_5>
sipa: It does generate valid signatures
< sipa>
apparently not
< sipa>
you're generating a signature that is different from the one created by bitcoin core
< sipa>
and it's not due to low-s
< sipa>
only one of both can be valid in that case
< 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
< GitHub24>
bitcoin/0.13 73adfe3 Jonas Schnelli: [Wallet] Correct hdmasterkeyid/masterkeyid name confusion...
< wumpus>
gah happy the heatwave in NL seems to have abated a bit
< 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
< 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)
< 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
< sdaftuar>
yeah that's basically what i was thinking. it's a little confusing the version number has two meanings
< sipa>
indeed
< sipa>
but the sendcmpct message already has two meanings as well
< sdaftuar>
yeah
< sipa>
1) i can offer compact blocks
< sipa>
2) i want you to potentially advertize using compact blocks, if you support it
< 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?
< sdaftuar>
i don't think there's any way to communicate to your peer that they made a mistake
< sipa>
yes
< sipa>
wumpus: not just in NL...
< sdaftuar>
so at the least, we should document that explicitly.
< sipa>
sdaftuar: now you bring it up, i feel like fixing it properly...
< sdaftuar>
that's also my preference :)
< * sipa>
hanging out with jonasschnelli
< sipa>
sdaftuar: so, in that case, i think sendcmpct should only have the meaning "i support compact blocks version up to X"
< sdaftuar>
and not distinguish sending/receiving?
< sdaftuar>
i think i'd agree with that
< sipa>
hmm, no... "i can send you version X compact blocks"
< sipa>
and a separate version for asking the peer to actually do that
< 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
< sipa>
well the protocol is not necessarily symmetric
< sipa>
one side may want inv using cmpctblock
< sipa>
while the other does not
< sdaftuar>
well we have the separate announcements bool inside the message
< sipa>
BlueMatt: ping ^
< 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
< sdaftuar>
prefer receiving*
< 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).
< sdaftuar>
(i have to ignore your first SENDCMPCT because it's too high version and i don't support it, as per the BIP)
< sipa>
who sends first?
< sdaftuar>
i don't think it matters, except that if you got mine first, you wouldn't bother sending a version=2 message
< sipa>
i find protocols that try to negotiate things for both directions hard to reason about
< 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?
< sdaftuar>
that's not strictly true of course, but just seems like not something we'd need to support
< sipa>
well a segwit node with wtxid-based table can encode compact blocks with txids or wtxids, but only decide wtxid based ones
< sipa>
s/decide/decode/
< sdaftuar>
fair point
< 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
< sdaftuar>
because in your example, you'd just never request compactblocks from the version1 peer
< sdaftuar>
by using announce=false, and not requesting compact blocks otherwise
< sipa>
right
< GitHub84>
[bitcoin] rebroad opened pull request #8403: Process "notfound" messages, and safeguard against unreasonably long … (master...ProcessNotfound) https://github.com/bitcoin/bitcoin/pull/8403
< DongSwanson>
can somebody help me with utilizing CHECKSEQUENCEVERIFY with bitcoin-core? I want to create a "escrow with timeout" with bitcoin-core
< jl2012>
DongSwanson: I think you can only do it manually. Try on the testnet first
< DongSwanson>
jl2012: what do you mean by manually?
< sipa>
DongSwanson: the wallet code can't sign such transactions
< sipa>
so you'll need to construct the scriptSig using other tools
< DongSwanson>
sipa: oh. so if I wanted to create a escrow with timeout for a real world scenario, we cannot use bitcoin-core?
< sipa>
DongSwanson: you can't use its wallet code for constructing such transactions
< 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
< sipa>
manually construct the contract (the easy part) and manually satisfy the contract (the hard part...)
< gmaxwell>
Creating it is not a big deal, but without a way to sign for it you will burn your funds.
< Chris_Stewart_5>
You can use something like peter todd's python bitcoin library or whatever library there is for your favorite language
< sipa>
or you can help review pull request 7601
< Chris_Stewart_5>
as sipa and gmaxwell said, best to experiment on testnet/regtest
< sipa>
which adds support for HTLC's (contracts which have a timelock and a hashlock)
< Chris_Stewart_5>
through bitcoin core's wallet UI?
< JackH>
there is a pull request for wallet features that enables "smarter" functions?
< DongSwanson>
so bitcoin-core cannot create CSV escrows but can sign it's outgoing transactions if you provide the correct redeemscript?
< JackH>
why are you guys keeping all these gems for yourself
< sipa>
it can create outputs to csv scripts
< sipa>
but it can't spend them
< sipa>
JackH: how do you mean to ourself?
< Chris_Stewart_5>
sipa: Even if you construct the inputs for the contract correctly, it won't be propogated will it?
< JackH>
I was joking because I didnt know about this myself
< JackH>
I know its public ;)
< sipa>
ha ok
< sipa>
Chris_Stewart_5: it's standard
< JackH>
I always wanted a core wallet with a bit more options unlocked, as we have nothing like that
< Chris_Stewart_5>
Hmm for some reason I thought redeem scripts needed to be standard scriptPubKey
< 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
< sipa>
Chris_Stewart_5: not anymore since a few releases
< sipa>
JackH: well CSV only activated a few weeks ago
< JackH>
yeah I can see in the pull maxwell says he will take a look at it after segwit
< DongSwanson>
so I guess I'll give it some more time
< DongSwanson>
thanks everybody for your input. I'll ask again in a few weeks. Be prepared :-)
< sipa>
DongSwanson: you can help make things move forward by testing the HTLC pull request, for example
< sipa>
waiting may work, helping gets you further
< DongSwanson>
good idea. Bitcoin has given me a lot. Maybe it is time to give something back. I'll look into that tomorrow.
< menix01>
anyboady talck here?
< sipa>
nope, never
< btcdrak>
I can confirm
< menix01>
and why you stay here peoples
< sipa>
to discuss the development of the software project called Bitcoin Core
< sipa>
see the topic
< menix01>
i see but u say noboady speack
< menix01>
that why\m comfuse
< sipa>
well, us saying that nobody says something is a clearly self-defeating statement
< sipa>
so perhaps it is a joke?
< menix01>
ok i was pm u private sipa
< sipa>
sorry, not interested
< menix01>
ok
< PatBoy>
thx for ur great work dev :)
< BlueMatt>
sdaftuar: sipa sorry, whats up?
< 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
< BlueMatt>
like, backward compat there is not hugely important to me?
< sipa>
BlueMatt: brb in 5 minutes
< sipa>
BlueMatt: i think the first question is more general about how to deal with multiple versions cmpctblocks
< sipa>
BlueMatt: because there is no way to negotiate
< BlueMatt>
hmm, I had a scheme in mind when I wrote it.....
< BlueMatt>
lemme go look
< 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
< BlueMatt>
ns."
< sipa>
BlueMatt: aha!
< sipa>
that sounds interesting
< BlueMatt>
intention was that, if you support version 2, you can just send 2 sendcmpct messages
< BlueMatt>
1 with version 1, one with version 2
< sipa>
i'll adapt bip and pr
< sipa>
actually, only pr
< gmaxwell>
also means you can stop supporting v1 at some point.
< sipa>
indeed
< sipa>
code now decides what to send based on whether the peer sets node_witness
< 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
< sipa>
but we shoukd just send both
< sipa>
and let the receiver decide
< BlueMatt>
yea, I was thinking do cmpctblockversion = max(all received sendcmpctblock messages)
< sipa>
*should
< BlueMatt>
but...whatever
< 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 ?