1 2017-04-04 01:41:19 <ajunas> im trying to compile the C library libbtc and I'm getting "__gmpn_ ... " undefined reference errors, but it claims to have no dependencies, is anyone familiar with that library?
 2 2017-04-04 09:43:34 <roasbeef> here's y'alls cool testnet transaction of the day: https://testnet.smartbit.com.au/tx/9e1d173e6362a3be3074dc73306e2dde2e50640f1027428f2204de29dcfd7c2e
 3 2017-04-04 16:42:50 <bsm117532> Can anyone point me to a good resource about transaction malleability, and the types that are possible?
 4 2017-04-04 16:43:36 <bsm117532> I have to rewrite some of my code to handle malleation because some idiots are blocking segwit, which I thought would have activated by now...
 5 2017-04-04 16:44:54 <instagibbs> bsm117532, https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki
 6 2017-04-04 16:45:26 <bsm117532> instagibbs: thanks I should have thought of bip62...
 7 2017-04-04 16:45:48 <instagibbs> well it was withdrawn in favor of segwit, so...
 8 2017-04-04 16:46:07 <bsm117532> Yeah.  But what I need is a review of malleation types.
 9 2017-04-04 16:46:19 <bsm117532> So I can handle it without segwit.
10 2017-04-04 16:46:39 <bsm117532> I'm going to have to track malleated versions of transactions...
11 2017-04-04 16:46:55 <bsm117532> And figure out how to identify if two transactions are actually the same. (malleated)
12 2017-04-04 16:47:12 <abpa> Just do your own hash?
13 2017-04-04 16:47:17 <abpa> Don't include the script signature
14 2017-04-04 16:47:45 <bsm117532> abpa: can't look up historical transactions from bitcoind if I introduce a new txn hash like that.
15 2017-04-04 16:48:19 <abpa> Do your own hash, add a database 1:many with the tx ids for that hash?
16 2017-04-04 16:49:06 <bsm117532> abpa: that's what I'm going to do, where "my own hash" is one of the malleated versions.
17 2017-04-04 16:49:51 <bsm117532> I don't suppose anyone has a handy `isMalleationOf` function lying around?  ;-)
18 2017-04-04 17:18:22 <danrobinson> ERIFY (on testnet fwiw).
19 2017-04-04 17:18:22 <danrobinson> Is there a convention for what an input's sequence number should be when that input uses OP_CHECKLOCKTIMEVERIFY but doesn't need relative lock time? bcoin seems to use 0xfffffffe (https://github.com/bcoin-org/bcoin/blob/42da82e00768487d3a51c8e3e5f085a06dd3a536/lib/primitives/mtx.js#L1297). I feel like I've seen 0 used elsewhere. I'm trying to manually build transactions that use OP_CHECKLOCKTIMEVERIFY but not OP_CHECKSEQUENCEV
20 2017-04-04 17:20:12 <instagibbs> danrobinson, the bip should describe this https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
21 2017-04-04 17:25:28 <danrobinson> instagibbs: as far as I can tell, it just checks that the sequence number is not "final" (0xffffffff). So either 0, or any sequence number with the disable bit set (such as 0xfffffffe), would work, I think. I'm just wondering if there is a convention (or standardness check, or higher-performance value, or something) for what it should be when it can't be final, but relative locktime behavior is not wanted.
22 2017-04-04 17:27:41 <instagibbs> I think just 0xfffffffe is fine
23 2017-04-04 17:28:14 <bsm117532> AFAICT several of the malleations in BIP62 are script malleations, so would only apply to P2PKH transactions, and could be avoided by using P2SH transactions, no?