Transcript for #bitcoin-dev 2017/02/05

10:44 McLovinMcLovin fork question: i have bought bitcoin some days ago, sent them through just a few wallets with bitWallet for ios. this goes from block 449795 (first tx) to block 451138 (last tx). all in all there are just 1-2 blocks in between i used for sending. are my coins already not existing in the BU/SW forks?
10:45 McLovinMcLovin bought them from kraken if that helps
10:46 McLovinMcLovin and the ios app bitwallet is some old schooler kind of thing wallet.
10:47 McLovinMcLovin here are list of all used blocks: 449795, 450739, 450259, 450243, 451138. hope this helps
17:21 aschildbach Hi there, I've got a question:
17:22 Wayward good luck with that
17:23 aschildbach What is the expected behaviour for wallets if they receive a version-2 transaction that otherwise looks like a standard pay-to-address tx? Assuming it pays to the wallet, shall be displayed, the value be added to the balance and be spendable?
17:23 aschildbach Clarification: Received in a block.
17:24 Wayward That's a #bitcoin question.
17:25 aschildbach Hu? I'm asking as a developer and it is a very technical question. Definately not for users.
17:25 Wayward This channel has been inactive for years. I just grepped, and the last 40 people who asked a question received no response.
17:25 aschildbach ok good to know
17:28 achow101 aschildbach: IIRC the only difference between v2 and v1 txs is that v2 allows relative time locks
17:30 aschildbach BIP68 I assume?
17:30 achow101 yes
17:32 aschildbach Ok thanks that's a great hint
17:33 arubi version 2 is for csv, bip 112
17:33 aschildbach Having read the BIP68 spec, after being mined such a tx is not different to v1 tx.
17:33 arubi op csv rules are only taken into account when the tx is v2, but currently core creates all tx's as version 2, at lease afaict
17:53 TZander if it does, thats a bug.
17:55 arubi why is that a bug? again, I'm usually using a very customized setup. what I see might not be what's actually the standard
17:57 arubi currently on (lightly) modified master and transactions created by -cli and -tx are version 2. just normal pay to pubkey hash
17:57 aschildbach Hmmm currently at least tx version 2 seems to be very rare. Otherwise I'd have more users complaining about their txns not appearing immediately.
17:58 aschildbach What's the behaviour on the latest release?
17:58 arubi aschildbach, I'm on testnet\regtest (and master), maybe things are a bit different. I do remember it being a policy not to relay weird version tx's, but not sure what's the state now
17:58 arubi what do you mean testnet release?
17:59 aschildbach I meant release of Bitcoin Core.
17:59 aschildbach You said master, but I'm interested what is being used by users.
17:59 arubi eyeballing some testnet block explorer, only seeing v1's for now
18:00 TZander check CURRENT_VERSION in transaction.h
18:00 arubi aschildbach, weird version transactions are valid in a block
18:00 TZander its set to 1
18:00 aschildbach Well there is at least one mined v2 transaction on mainnet: 0321b1413ed9048199815bd6bc2650cab1a9e8d543f109a42c769b1f18df4174
18:00 aschildbach But I guess there are many more
18:03 TZander there is unfortunately no consensus rule that forbids version numbers for transactions not defined. Its a policy rule.
18:03 arubi hm. I wonder if it's setting version 2 due to use of locktime (current block)
18:03 TZander on testnet you'll find loads of interesting version numbers
18:03 arubi current_version says 1, right
18:04 TZander arubi: and thats used in cmutable_transaction
18:04 TZander and as such the wallet
18:04 arubi well I'm reporting what I see. I don't see how my current setup can interfere
18:05 arubi sorry, have to go back to crunching other numbers :)
18:07 aschildbach Ok, my investigation yields: v0.13.2 uses 1, master uses 2. Is v0.14 already branched?
18:07 achow101 branching will probably happen tomorrow
18:07 achow101 or in a few days
18:11 TZander aschildbach: my suggestion is to have a two layer approach. If a tx.nversion == 2, check the sequence mask to see if anything is set. If that is the case, you either want to check the logic itself, or just make funds unspendable until they are known to be in a block.
18:12 arubi no. read bip112. if you encounter op_csv in a redeeming script, do check for all the things mentioned (version == 2 being one of them) and validate or not according to the rules
18:13 TZander thats what my "check the logic itself" means.
18:13 arubi should happen first. you shouldn't care at all about what version a tx is if it's in a block. go ahead and don't relay whatever you don't want to though
18:14 arubi also, csv rules only make sense when an input is redeemed, so of course it's already in a block
18:16 arubi well I take that back
18:16 TZander that makes no sense... A wallet can recieve a transaction that redeems a transaction that has op-csv.
18:17 arubi yea, and that tx paying to op_csv can even be version 1. the redeeming one is version 2. pebkac
18:17 TZander I understand, it took me a bit to get my head around this too ;)
18:19 arubi yep, I love when I suddenly realize some confusion I'm having about these things, and it's not like I never did csv\cltv transactions before, just gets a bit confusing for humans :)
18:19 achow101 ok, so as I understand this, v2 txs are considered standard because the csv softfork activated. this means that v2 txs are being mined and relayed
18:20 arubi nice, good to know.
18:20 achow101 bitcoin core will default to making v2 txs in 0.14+. se https://github.com/bitcoin/bitcoin/pull/7562
18:20 achow101 *see
18:20 arubi yay
19:16 aschildbach arubi: For now, I will probably only check the "disabled" bit. However, I'm currently puzzled by how/if BIP68 interacts with opt-in RBF. Both use the sequence field if I'm not mistaken.
19:20 arubi aschildbach, so consider the conditions for redeeming anything csv or cltv
19:20 arubi if such an opcode exists in the script, you should check the tx as bip68 rules
19:21 arubi if not, then you haven't even tried to check it and just raised the rbf flag way before that
19:22 arubi as the signer of a tx, you're pretty much always free to change the sequence and send again. it's an awesome feature, and combined with cltv, csv or rbf, it has different meanings
19:23 arubi so really you shouldn't be considering any rule until you come to parse it. of course a csv\cltv transaction is replaceable. another sequence exists that satisfies the cltv\csv opcodes which might appear in the script
19:23 arubi you just raise the rbf flag, and consider everything replaceable anyway
19:24 aschildbach Somehow this is over my horizon... )-: For now at least.
19:24 aschildbach I'm currently only looking at transaction, not creating them.
19:25 arubi right, but unless you're always expecting to parse transactions to addresses that you know how to parse, you'll have to actually implement every bip that exists
19:25 aschildbach So if the RBF spec is valid for version 2 transactions too that means you can use BIP68 only if a tx is RBF at the same time.
19:25 aschildbach Right?
19:26 arubi a tx is marked rbf if the sequence is less than so and so. a tx is marked non csv or clrv if the sequence is max_sequence
19:26 arubi so you see, there's no overlap :)
19:26 arubi s/clrv/cltv
19:27 aschildbach Hu, BIP68 talks about a disable bit. It's not a sequence == MAX_SEQUENCE rule.
19:28 aschildbach And besides, MAX_SEQUENCE = 0xffffffff?
19:28 arubi you're right, it's a bunch of sequences. even better
19:28 arubi aschildbach, you may encounter op_csv or op_cltv where the sequence says that it's disabled
19:29 arubi you have to treat these opcodes as op_nops. you look for the sequence (and other rules) to validate
19:29 aschildbach All I need to know is if the features are enabled.
19:29 arubi well, specifically op_csv, maybe not cltv ?
19:30 aschildbach I'm not doing any script evaluation.
19:30 aschildbach (I == bitcoinj)
19:30 arubi hm. so just wait until they're in a block
19:30 arubi act like a pre-softfork node. just assume non-relay and ignored until it's mined
19:31 aschildbach Yes if the tx in a block it's decided anyhow.
19:31 aschildbach But I want to know beforehand.
19:31 arubi that's the best you can do. don't try to act on non confirmed
19:32 arubi aschildbach, bitcoinj is used by wallets right? don't assume anything until it's mined if you're not going to validate it
19:32 aschildbach Well, unconfirmed txns are shown to the user (if low risk), so some acting is needed
19:33 aschildbach Yes bitcoinj is mostly aimed at wallets, but some devs use it for different things too
19:33 arubi but you do currently check for some things right? if you can't check for soft forked rules, just ignore transactions that use them
19:34 arubi you don't need to parse or validate anything, just implement the "how to check if this is enabled" part of the bips I guess
19:34 aschildbach Yes, exactly that is my point.
19:34 aschildbach I currently do check for RBF.
19:35 aschildbach Now for version 2 txns I need to check for RBF AND BIP68 enable bit I guess
19:35 aschildbach So I'm trying to understand how these two interacgt.
19:35 arubi any tx with a sequence set that activates rbf is rbf.
19:36 aschildbach Yes that rule is part of RBF.
19:36 arubi now, if you see op cltv in the script, you check of disabled bit. if you see op csv and it's version 2, you check for disabled bit
19:37 aschildbach I'm not going to see any script opcode, because I don't parse scripts.
19:37 aschildbach So I just check the disabled bit, right?
19:38 arubi yea, I guess, but.. you don't parse scripts at all?
19:38 arubi not even normal ones?
19:38 aschildbach The funny thing is for non-RBF inputs the disabled bit will always be set
19:38 arubi right, because it's 0xfff...
19:38 aschildbach Because non-RBF txns either use 0xffffffff or 0xfffffffe as a sequence
19:38 aschildbach Maybe that's be design
19:38 arubi really anything 0x07... is set
19:39 arubi I'm pretty sure that's the right bit
19:39 arubi well yea endian-ness
19:40 arubi 0xffffff7f is set, I /think/
19:40 aschildbach No RBF is "sequence < NO_SEQUENCE - 1" I'm pretty sure
19:41 arubi yea rbf is anything lower than 0xfffffffe, core sets 2^32-3, pretty sure
19:41 arubi I mean the disabled bit
19:43 aschildbach I think in the current release it depends if you use the CLI or the UI.
19:43 arubi you can set it with 'walletrbf=1' for cli, not sure if it sticks with gui
19:43 aschildbach or the JSON interface
19:52 aschildbach Ok but many thanks for the explanations. I think for now I know enough.
19:59 arubi cheers