1 2017-02-05 10:44:59 <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?
  2 2017-02-05 10:45:32 <McLovinMcLovin> bought them from kraken if that helps
  3 2017-02-05 10:46:06 <McLovinMcLovin> and the ios app bitwallet is some old schooler kind of thing wallet.
  4 2017-02-05 10:47:29 <McLovinMcLovin> here are list of all used blocks: 449795, 450739, 450259, 450243, 451138. hope this helps
  5 2017-02-05 17:21:52 <aschildbach> Hi there, I've got a question:
  6 2017-02-05 17:22:04 <Wayward> good luck with that
  7 2017-02-05 17:23:06 <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?
  8 2017-02-05 17:23:48 <aschildbach> Clarification: Received in a block.
  9 2017-02-05 17:24:20 <Wayward> That's a #bitcoin question.
 10 2017-02-05 17:25:01 <aschildbach> Hu? I'm asking as a developer and it is a very technical question. Definately not for users.
 11 2017-02-05 17:25:26 <Wayward> This channel has been inactive for years.  I just grepped, and the last 40 people who asked a question received no response.
 12 2017-02-05 17:25:54 <aschildbach> ok good to know
 13 2017-02-05 17:28:55 <achow101> aschildbach: IIRC the only difference between v2 and v1 txs is that v2 allows relative time locks
 14 2017-02-05 17:30:35 <aschildbach> BIP68 I assume?
 15 2017-02-05 17:30:39 <achow101> yes
 16 2017-02-05 17:32:43 <aschildbach> Ok thanks that's a great hint
 17 2017-02-05 17:33:06 <arubi> version 2 is for csv, bip 112
 18 2017-02-05 17:33:29 <aschildbach> Having read the BIP68 spec, after being mined such a tx is not different to v1 tx.
 19 2017-02-05 17:33:56 <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
 20 2017-02-05 17:53:40 <TZander> if it does, thats a bug.
 21 2017-02-05 17:55:45 <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
 22 2017-02-05 17:57:51 <arubi> currently on (lightly) modified master and transactions created by -cli and -tx are version 2.  just normal pay to pubkey hash
 23 2017-02-05 17:57:51 <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.
 24 2017-02-05 17:58:21 <aschildbach> What's the behaviour on the latest release?
 25 2017-02-05 17:58:37 <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
 26 2017-02-05 17:58:50 <arubi> what do you mean testnet release?
 27 2017-02-05 17:59:30 <aschildbach> I meant release of Bitcoin Core.
 28 2017-02-05 17:59:42 <aschildbach> You said master, but I'm interested what is being used by users.
 29 2017-02-05 17:59:59 <arubi> eyeballing some testnet block explorer, only seeing v1's for now
 30 2017-02-05 18:00:16 <arubi> aschildbach, weird version transactions are valid in a block
 31 2017-02-05 18:00:16 <TZander> check CURRENT_VERSION in transaction.h
 32 2017-02-05 18:00:40 <TZander> its set to 1
 33 2017-02-05 18:00:54 <aschildbach> Well there is at least one mined v2 transaction on mainnet: 0321b1413ed9048199815bd6bc2650cab1a9e8d543f109a42c769b1f18df4174
 34 2017-02-05 18:00:59 <aschildbach> But I guess there are many more
 35 2017-02-05 18:03:12 <TZander> there is unfortunately no consensus rule that forbids version numbers for transactions not defined.  Its a policy rule.
 36 2017-02-05 18:03:14 <arubi> hm.  I wonder if it's setting version 2 due to use of locktime (current block)
 37 2017-02-05 18:03:38 <TZander> on testnet you'll find loads of interesting version numbers
 38 2017-02-05 18:03:44 <arubi> current_version says 1, right
 39 2017-02-05 18:04:15 <TZander> arubi: and thats used in cmutable_transaction
 40 2017-02-05 18:04:29 <TZander> and as such the wallet
 41 2017-02-05 18:04:53 <arubi> well I'm reporting what I see.  I don't see how my current setup can interfere
 42 2017-02-05 18:05:42 <arubi> sorry, have to go back to crunching other numbers :)
 43 2017-02-05 18:07:16 <aschildbach> Ok, my investigation yields: v0.13.2 uses 1, master uses 2. Is v0.14 already branched?
 44 2017-02-05 18:07:28 <achow101> branching will probably happen tomorrow
 45 2017-02-05 18:07:33 <achow101> or in a few days
 46 2017-02-05 18:11:50 <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.
 47 2017-02-05 18:12:57 <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
 48 2017-02-05 18:13:20 <TZander> thats what my "check the logic itself" means.
 49 2017-02-05 18:13:47 <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
 50 2017-02-05 18:14:39 <arubi> also, csv rules only make sense when an input is redeemed, so of course it's already in a block
 51 2017-02-05 18:16:27 <arubi> well I take that back
 52 2017-02-05 18:16:33 <TZander> that makes no sense...   A wallet can recieve a transaction that redeems a transaction that has op-csv.
 53 2017-02-05 18:17:06 <arubi> yea, and that tx paying to op_csv can even be version 1.  the redeeming one is version 2.  pebkac
 54 2017-02-05 18:17:23 <TZander> I understand, it took me a bit to get my head around this too ;)
 55 2017-02-05 18:19:05 <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 :)
 56 2017-02-05 18:19:51 <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
 57 2017-02-05 18:20:20 <arubi> nice, good to know.
 58 2017-02-05 18:20:40 <achow101> bitcoin core will default to making v2 txs in 0.14+. se https://github.com/bitcoin/bitcoin/pull/7562
 59 2017-02-05 18:20:47 <achow101> *see
 60 2017-02-05 18:20:53 <arubi> yay
 61 2017-02-05 19:16:27 <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.
 62 2017-02-05 19:20:06 <arubi> aschildbach, so consider the conditions for redeeming anything csv or cltv
 63 2017-02-05 19:20:40 <arubi> if such an opcode exists in the script, you should check the tx as bip68 rules
 64 2017-02-05 19:21:10 <arubi> if not, then you haven't even tried to check it and just raised the rbf flag way before that
 65 2017-02-05 19:22:12 <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
 66 2017-02-05 19:23:20 <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
 67 2017-02-05 19:23:45 <arubi> you just raise the rbf flag, and consider everything replaceable anyway
 68 2017-02-05 19:24:11 <aschildbach> Somehow this is over my horizon... )-:  For now at least.
 69 2017-02-05 19:24:26 <aschildbach> I'm currently only looking at transaction, not creating them.
 70 2017-02-05 19:25:21 <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
 71 2017-02-05 19:25:22 <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.
 72 2017-02-05 19:25:28 <aschildbach> Right?
 73 2017-02-05 19:26:06 <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
 74 2017-02-05 19:26:13 <arubi> so you see, there's no overlap :)
 75 2017-02-05 19:26:50 <arubi> s/clrv/cltv
 76 2017-02-05 19:27:38 <aschildbach> Hu, BIP68 talks about a disable bit. It's not a sequence == MAX_SEQUENCE rule.
 77 2017-02-05 19:28:00 <aschildbach> And besides, MAX_SEQUENCE = 0xffffffff?
 78 2017-02-05 19:28:03 <arubi> you're right, it's a bunch of sequences.  even better
 79 2017-02-05 19:28:43 <arubi> aschildbach, you may encounter op_csv or op_cltv where the sequence says that it's disabled
 80 2017-02-05 19:29:20 <arubi> you have to treat these opcodes as op_nops.  you look for the sequence (and other rules) to validate
 81 2017-02-05 19:29:51 <aschildbach> All I need to know is if the features are enabled.
 82 2017-02-05 19:29:57 <arubi> well, specifically op_csv, maybe not cltv ?
 83 2017-02-05 19:30:03 <aschildbach> I'm not doing any script evaluation.
 84 2017-02-05 19:30:13 <aschildbach> (I == bitcoinj)
 85 2017-02-05 19:30:33 <arubi> hm.  so just wait until they're in a block
 86 2017-02-05 19:30:58 <arubi> act like a pre-softfork node.  just assume non-relay and ignored until it's mined
 87 2017-02-05 19:31:05 <aschildbach> Yes if the tx in a block it's decided anyhow.
 88 2017-02-05 19:31:18 <aschildbach> But I want to know beforehand.
 89 2017-02-05 19:31:27 <arubi> that's the best you can do.  don't try to act on non confirmed
 90 2017-02-05 19:32:02 <arubi> aschildbach, bitcoinj is used by wallets right?  don't assume anything until it's mined if you're not going to validate it
 91 2017-02-05 19:32:37 <aschildbach> Well, unconfirmed txns are shown to the user (if low risk), so some acting is needed
 92 2017-02-05 19:33:02 <aschildbach> Yes bitcoinj is mostly aimed at wallets, but some devs use it for different things too
 93 2017-02-05 19:33:29 <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
 94 2017-02-05 19:34:02 <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
 95 2017-02-05 19:34:36 <aschildbach> Yes, exactly that is my point.
 96 2017-02-05 19:34:44 <aschildbach> I currently do check for RBF.
 97 2017-02-05 19:35:12 <aschildbach> Now for version 2 txns I need to check for RBF AND BIP68 enable bit I guess
 98 2017-02-05 19:35:26 <aschildbach> So I'm trying to understand how these two interacgt.
 99 2017-02-05 19:35:39 <arubi> any tx with a sequence set that activates rbf is rbf.
100 2017-02-05 19:36:04 <aschildbach> Yes that rule is part of RBF.
101 2017-02-05 19:36:37 <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
102 2017-02-05 19:37:18 <aschildbach> I'm not going to see any script opcode, because I don't parse scripts.
103 2017-02-05 19:37:31 <aschildbach> So I just check the disabled bit, right?
104 2017-02-05 19:38:00 <arubi> yea, I guess, but.. you don't parse scripts at all?
105 2017-02-05 19:38:14 <arubi> not even normal ones?
106 2017-02-05 19:38:20 <aschildbach> The funny thing is for non-RBF inputs the disabled bit will always be set
107 2017-02-05 19:38:37 <arubi> right, because it's 0xfff...
108 2017-02-05 19:38:42 <aschildbach> Because non-RBF txns either use 0xffffffff or 0xfffffffe as a sequence
109 2017-02-05 19:38:47 <aschildbach> Maybe that's be design
110 2017-02-05 19:38:48 <arubi> really anything 0x07... is set
111 2017-02-05 19:39:00 <arubi> I'm pretty sure that's the right bit
112 2017-02-05 19:39:33 <arubi> well yea endian-ness
113 2017-02-05 19:40:08 <arubi> 0xffffff7f is set, I /think/
114 2017-02-05 19:40:46 <aschildbach> No RBF is "sequence < NO_SEQUENCE - 1" I'm pretty sure
115 2017-02-05 19:41:33 <arubi> yea rbf is anything lower than 0xfffffffe, core sets 2^32-3, pretty sure
116 2017-02-05 19:41:52 <arubi> I mean the disabled bit
117 2017-02-05 19:43:15 <aschildbach> I think in the current release it depends if you use the CLI or the UI.
118 2017-02-05 19:43:48 <arubi> you can set it with 'walletrbf=1' for cli, not sure if it sticks with gui
119 2017-02-05 19:43:58 <aschildbach> or the JSON interface
120 2017-02-05 19:52:22 <aschildbach> Ok but many thanks for the explanations. I think for now I know enough.
121 2017-02-05 19:59:33 <arubi> cheers