Transcript for #bitcoin-dev 2017/04/04

01:41 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?
09:43 roasbeef here's y'alls cool testnet transaction of the day:
16:42 bsm117532 Can anyone point me to a good resource about transaction malleability, and the types that are possible?
16:43 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...
16:44 instagibbs bsm117532,
16:45 bsm117532 instagibbs: thanks I should have thought of bip62...
16:45 instagibbs well it was withdrawn in favor of segwit, so...
16:46 bsm117532 Yeah. But what I need is a review of malleation types.
16:46 bsm117532 So I can handle it without segwit.
16:46 bsm117532 I'm going to have to track malleated versions of transactions...
16:46 bsm117532 And figure out how to identify if two transactions are actually the same. (malleated)
16:47 abpa Just do your own hash?
16:47 abpa Don't include the script signature
16:47 bsm117532 abpa: can't look up historical transactions from bitcoind if I introduce a new txn hash like that.
16:48 abpa Do your own hash, add a database 1:many with the tx ids for that hash?
16:49 bsm117532 abpa: that's what I'm going to do, where "my own hash" is one of the malleated versions.
16:49 bsm117532 I don't suppose anyone has a handy `isMalleationOf` function lying around? ;-)
17:18 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 ( I feel like I've seen 0 used elsewhere. I'm trying to manually build transactions that use OP_CHECKLOCKTIMEVERIFY but not OP_CHECKSEQUENCEV
17:18 danrobinson ERIFY (on testnet fwiw).
17:20 instagibbs danrobinson, the bip should describe this
17:25 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.
17:27 instagibbs I think just 0xfffffffe is fine
17:28 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?