1 2017-12-24 00:12:55 <eck> how do i enable segwit for a regtest bitcoind instance
 2 2017-12-24 00:13:51 <eck> when i use the addwitnessaddress rpc with my regtest node i get an error "Segregated witness not enabled on network"
 3 2017-12-24 00:14:39 <eck> oh it appears i just needed to generate more blocks
 4 2017-12-24 00:14:43 <eck> got it now
 5 2017-12-24 03:29:49 <jb55> updated my bitcoin unit calculator: https://github.com/jb55/bcalc I've expanded the grammer so it can do stuff like: 'bcalc 100 mbtc + 300 bits in btc' -> 0.1003 BTC
 6 2017-12-24 04:27:15 <eck> what is the vsize in decoderawtransaction
 7 2017-12-24 04:27:29 <eck> i thought it was block weight, but in that case i would have expected it to be at least as large as size
 8 2017-12-24 04:34:20 <eck> i think i get it now
 9 2017-12-24 04:34:22 <eck> src/core_write.cpp:    entry.pushKV("vsize", (GetTransactionWeight(tx) + WITNESS_SCALE_FACTOR - 1) / WITNESS_SCALE_FACTOR);
10 2017-12-24 04:58:54 <adiabat> eck: vsize is just weight / 4
11 2017-12-24 04:59:10 <adiabat> which is kindof confusing that both appear in different places
12 2017-12-24 05:03:06 <eck> the extra + 3 term was throwing me off but i realize now it's to force the value to be rounded up to the next integer
13 2017-12-24 05:08:48 <eck> how do you create a native (not embedded within p2sh) p2wpkh address with bitcoin core?
14 2017-12-24 07:02:24 <DSidH> eck: I am not an expert on segwit but I think its not possible to have native (non-P2SH) segwit address.
15 2017-12-24 07:04:59 <eck> they're in bip141: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#P2WPKH
16 2017-12-24 07:05:17 <eck> but it looks like there's only human-readable syntax for them defined in bech32
17 2017-12-24 07:21:45 <DSidH> yes I have not seen much about non P2SH P2WKH addresses
18 2017-12-24 07:22:40 <DSidH> quick question: Even if I start using segwit, I won't see much difference in tx confirmation time if rest of the network is not using it.. Right?
19 2017-12-24 07:22:53 <eck> it will not affect tx confirmation time at all
20 2017-12-24 07:23:56 <eck> from a miner's pov the best thing to do is to include the most profitable transactions, whether they are segwit or not
21 2017-12-24 07:24:27 <DSidH> yup but since the segwit tx will be smaller, it will be equivalent to a
22 2017-12-24 07:24:31 <DSidH> "high fee" normal tx
23 2017-12-24 07:25:13 <DSidH> unless the miner thinks that even having extra witness payload is "not profitable"
24 2017-12-24 07:26:12 <eck> also note, you only get the lower block weight if you're spending *from* a sw address
25 2017-12-24 07:29:45 <DSidH> yup, and that too a pure segwit tx, since mixed inputs don't give as much benefit
26 2017-12-24 07:33:52 <DSidH> I am having trouble understanding the RFC6979 for deterministic generation of k values for ECDSA
27 2017-12-24 07:34:16 <DSidH> Is there a dummies version of it? What do others use for deterministic k values?
28 2017-12-24 07:34:57 <DSidH> this is the document: https://tools.ietf.org/html/rfc6979
29 2017-12-24 07:35:35 <arubi> what are you not understanding,  it's pretty much a bunch of hmac-sha512
30 2017-12-24 07:35:50 <DSidH> I got lost in various bit conversions
31 2017-12-24 07:36:45 <DSidH> and the examples do not use Secp256k1 so I am not able to test the algorithm
32 2017-12-24 07:36:59 <DSidH> are there any test vectors for Secp256k1 for this algorithm?
33 2017-12-24 07:37:25 <arubi> https://github.com/fivepiece/btc-bash-ng/blob/master/ecdsa/rfc6979.sh and https://github.com/fivepiece/btc-bash-ng/blob/master/ecdsa/.tests/test_rfc6979.sh
34 2017-12-24 07:37:29 <DSidH> (examples in the rfc use ansix9t163k1)
35 2017-12-24 07:38:01 <arubi> hmac itself is https://github.com/fivepiece/btc-bash-ng/blob/master/hash/hmac.sh
36 2017-12-24 07:38:29 <DSidH> arubi: thanks.. these should help
37 2017-12-24 07:38:32 <arubi> but -- I'm a hobbyist, this is definitely not something you should use on actual money :)
38 2017-12-24 07:41:54 <DSidH> arubi: you mean the test vectors may not be correct or the RFC itself may not be secure ?
39 2017-12-24 07:41:56 <arubi> s/hmac-sha512/hmac-sha256/ .  got confused with bip32
40 2017-12-24 07:42:13 <arubi> the test vectors are correct, this code is consistent with what core gets for k
41 2017-12-24 07:42:26 <arubi> but maybe I got some edge case wrong, not sure.  it's hard to know
42 2017-12-24 07:48:38 <DSidH> and does core also use RFC6979 ?
43 2017-12-24 07:49:30 <echeveria> the underlying crypto library does.
44 2017-12-24 07:52:20 <arubi> right, the code is in libsecp256k1
45 2017-12-24 07:52:20 <DSidH> ok so I think Im on the right track. I was otherwise thinking of writing a custom algorithm for k = Hash(x, h)
46 2017-12-24 07:53:44 <arubi> if it's just for testnet then it's fine, but there has to be a good reason for a simple hash(x,h) not being used
47 2017-12-24 08:04:28 <DSidH> its currently testnet but the goal is to use in mainnet
48 2017-12-24 08:22:33 <arubi> ah, alright.  probably best to use the standard practices then
49 2017-12-24 14:50:26 <DSidH> eck: https://bitcoincore.org/en/segwit_wallet_dev/ based on this the only examples are P2SH-P2WPKH.
50 2017-12-24 14:51:36 <DSidH> I mean the others don't seem to be that popular
51 2017-12-24 15:09:49 <arubi> what else are you looking for DSidH ?
52 2017-12-24 16:10:01 <DSidH> arubi: I am good for now. Just need to test my RFC implementation.
53 2017-12-24 16:10:19 <arubi> cool DSidH
54 2017-12-24 16:11:00 <DSidH> arubi: btw you saved me several days ot trial and error
55 2017-12-24 16:11:20 <arubi> yw :)