1 2016-10-11 11:08:20 <TZander> Can someone here tell me the logic behind making CSV be part of an input instead of to an output?
 2 2016-10-11 11:46:59 <jl2012> TZander, are you talking about BIP68, or 112, or something else?
 3 2016-10-11 11:47:21 <TZander> those, yes
 4 2016-10-11 11:47:35 <TZander> 112 specifies most of it.
 5 2016-10-11 11:47:40 <jl2012> 68 and 112 are related but not the same thing
 6 2016-10-11 11:47:57 <jl2012> 112 is the op_code
 7 2016-10-11 11:48:09 <jl2012> 68 is the relative lock time
 8 2016-10-11 11:48:28 <jl2012> 112 depends on 68. But 68 could work without 112
 9 2016-10-11 11:49:03 <jl2012> BIP68 is the relative locktime version of the original nLockTime
10 2016-10-11 11:49:18 <jl2012> BIP112 is the relative locktime version of BIP65
11 2016-10-11 11:49:31 <TZander> in 112 there is an example; if [multisig] else if [30d CSV], then pay to address X.    This would presumably be an output script, so then where does that 30d value come from?
12 2016-10-11 11:50:00 <jl2012> it's part of the scriptPubKey, or the P2SH redeemScript
13 2016-10-11 11:50:18 <TZander> if just from a push in the script, then what reason is there to store anything in the sequence?
14 2016-10-11 11:50:42 <jl2012> that's why i said 68 and 112 are different things
15 2016-10-11 11:51:05 <jl2012> I think you are actually asking for 68
16 2016-10-11 11:51:45 <jl2012> the nSequence is used because it is the only part in the transaction that is unused
17 2016-10-11 11:52:21 <jl2012> it is unused but spending 4 bytes per input, which is a waste of resources after so many years
18 2016-10-11 11:53:03 <TZander> ok, so does a transaction that specifies a block-height in input 1 use that value in the same transaction's output 1?   Or is it something else?
19 2016-10-11 11:53:33 <jl2012> not necessarily
20 2016-10-11 11:53:46 <jl2012> just like you could use nLockTime without BIP65
21 2016-10-11 11:53:57 <jl2012> you could use BIP68 without BIP112
22 2016-10-11 11:55:51 <TZander> What effect would it have to set a sequence field to, for instance, spend in 10 blocks?
23 2016-10-11 11:56:25 <TZander> which output would specificially be targetted with it
24 2016-10-11 11:58:32 <jl2012> it means: unless this input is confirmed for more than 10 blocks, this tx is invalid
25 2016-10-11 11:59:06 <jl2012> (or confirmed for at least 10 blocks, I think)
26 2016-10-11 12:00:00 <jl2012> it's not targeting a particular output, it's target the validity of the whole tx
27 2016-10-11 12:00:16 <jl2012> just like nLockTime
28 2016-10-11 12:00:32 <jl2012> the tx is invalid until the locktime is reached
29 2016-10-11 12:03:41 <TZander> ok, sounds like the usage of the input here is pure technical debt..     Makes me wonder why a simple 'push' of 2 bytes in the output wasn't used instead.
30 2016-10-11 12:04:12 <TZander> the outputs scriptPubKeys, I mean
31 2016-10-11 12:04:45 <jl2012> no you can't
32 2016-10-11 12:05:16 <jl2012> because you can't change your mind if you push that to the scriptPubKey
33 2016-10-11 12:05:27 <jl2012> what you are talking about is BIP112
34 2016-10-11 12:06:07 <TZander> not being able to change your mind is kind of the idea, isn't it?
35 2016-10-11 12:06:50 <jl2012> BIP68 allows you to change your mind; BIP112 not allows you to change your mind. They are different use case
36 2016-10-11 12:07:43 <TZander> aha
37 2016-10-11 12:07:47 <jl2012> say you give a BIP68 sequence locked tx to someone, but you may still change your mind before it is confirmed
38 2016-10-11 12:21:09 <TZander> jl2012: I think I grasp all the concepts and all the flaws ;)
39 2016-10-11 12:21:44 <jl2012> what are the flaws you found?
40 2016-10-11 12:24:28 <TZander> the usage of an input instead of a tx-wide field.  The fact that we can have multiple inputs, which won't really make sense.
41 2016-10-11 12:25:10 <TZander> That the spec depends on the usage of the nSequence even if the script also specifies it.  Thats a waste of bytes.
42 2016-10-11 12:27:25 <TZander> maybe better to call them technical debt. They are not flaws or bugs themselves
43 2016-10-11 12:27:33 <TZander> they could be
44 2016-10-11 12:29:49 <arubi> TZander, the value being checked against the sequence means that the signer did intend for that value to appear on the stack (assuming it was pushed in there from scriptsig)
45 2016-10-11 12:30:29 <arubi> it's a way to sign that specific input, as the sequence is signed
46 2016-10-11 12:30:49 <arubi> at least that's how I understand bip112
47 2016-10-11 12:32:28 <TZander> the sequence is signed, yes, the outputs scriptPubKey is also signed.
48 2016-10-11 12:32:40 <arubi> but the value doesn't have to be in the output
49 2016-10-11 12:32:55 <arubi> it could be pushed in there when redeeming
50 2016-10-11 12:37:09 <TZander> a redeem script that would specify the timeout would make no sense, now would it?
51 2016-10-11 12:37:26 <TZander> I can just spend something after setting the block timeout to 1
52 2016-10-11 12:38:01 <arubi> what do you mean?  a redeemscript specifying the timeout is the normal use case
53 2016-10-11 12:38:58 <TZander> I'm trying to understand your usecase;  "but the value doesn't have to be in the output. it could be pushed in there when redeeming".
54 2016-10-11 12:39:37 <TZander> What I read there is that an input script pushed it while redeeming, which I don't understand.
55 2016-10-11 12:42:13 <arubi> the value that is checked by op_csv does not have to be in the output (and as a result in redeemscript).  it could be an independent push like any data push, or a result by some math operation, or whatever
56 2016-10-11 12:43:35 <arubi> since there's no way to sign the stuff that get pushed when redeeming (redeemscript\prevout is signed in sighash), then checking that value against the sequence helps against anybody trying to change the value before the tx is mined
57 2016-10-11 12:57:17 <TZander> any tx that uses a timespan that is on stack, but not pushed there by the redeemscript is broken.
58 2016-10-11 12:57:59 <TZander> it should not use CSV if it doesn't specify the timeout
59 2016-10-11 13:06:51 <arubi> I don't think that's true.  I think it has one interesting use case where multiple signing parties would like to make use of op_csv and keep the actual redeemscript static.  one party might propose a value for op_csv, and by signing with it in the sequence the rest are "agreeing"
60 2016-10-11 13:23:13 <TZander> That usecase is interesting but doesn't support your position for using nSequence.
61 2016-10-11 13:25:49 <arubi> but that's exactly how a signer agrees to a specific value, if it weren't for the signed sequence the signature would be valid for all input values
62 2016-10-11 14:10:37 <jl2012> TZander: please make a counter proposal that allows people to change their minds
63 2016-10-11 14:22:50 <TZander> jl2012: I think we'll have to have a next version of Script where many of these things can be fixed. It would not make sense to have a hard fork for a single opcode being fixed
64 2016-10-11 14:24:28 <jl2012> With segwit, you could add this field to witness
65 2016-10-11 14:24:48 <jl2012> But BIP68 was proposed long before segwit
66 2016-10-11 14:31:10 <TZander> Using Flextrans you should be able to drop the timelimit altogether in the usecase its already part of your output script. Only use the token if you must, and do it as a single transaction-wide token instead of repeated per input.
67 2016-10-11 14:31:54 <TZander> But I guess that BIP112 would object when the nSequence is final. So that would be the next script version I mentioned.