--- Log opened Thu Nov 28 00:00:21 2019 00:00 -!- wk057 [~wk@unaffiliated/wizkid057] has joined #bitcoin-wizards 00:01 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 245 seconds] 00:09 -!- tromp [~tromp@2a02:a210:1585:3200:b1dd:28c9:60ff:6663] has joined #bitcoin-wizards 00:19 -!- wk057 [~wk@unaffiliated/wizkid057] has quit [Read error: Connection reset by peer] 00:23 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-wizards 00:24 -!- wk057 [~wk@unaffiliated/wizkid057] has joined #bitcoin-wizards 00:25 -!- wk057 [~wk@unaffiliated/wizkid057] has quit [Read error: Connection reset by peer] 00:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards 00:36 -!- wk057 [~wk@unaffiliated/wizkid057] has joined #bitcoin-wizards 00:39 -!- wk057 [~wk@unaffiliated/wizkid057] has quit [Read error: Connection reset by peer] 00:42 -!- tromp [~tromp@2a02:a210:1585:3200:b1dd:28c9:60ff:6663] has quit [Remote host closed the connection] 00:43 -!- antanst- [~antanst@62.169.219.213] has quit [Ping timeout: 245 seconds] 00:43 -!- antanst [~antanst@62.169.219.213] has joined #bitcoin-wizards 00:44 -!- wk057 [~wk@unaffiliated/wizkid057] has joined #bitcoin-wizards 00:46 -!- wk057 [~wk@unaffiliated/wizkid057] has quit [Read error: Connection reset by peer] 00:51 -!- Socoro [~mix@141.98.103.204] has joined #bitcoin-wizards 00:51 -!- wk057 [~wk@unaffiliated/wizkid057] has joined #bitcoin-wizards 00:53 -!- wk057 [~wk@unaffiliated/wizkid057] has quit [Read error: Connection reset by peer] 00:58 -!- wk057 [~wk@unaffiliated/wizkid057] has joined #bitcoin-wizards 01:00 -!- alorente [~alorente@77.243.177.38] has quit [] 01:04 -!- marcoagner [~user@bl11-16-162.dsl.telepac.pt] has joined #bitcoin-wizards 01:13 -!- CryptoDavid_ [uid14990@gateway/web/irccloud.com/x-gcksjszmqkrjvmvx] has joined #bitcoin-wizards 01:16 -!- tromp [~tromp@2a02:a210:1585:3200:b1dd:28c9:60ff:6663] has joined #bitcoin-wizards 01:21 -!- CryptoDavid_ [uid14990@gateway/web/irccloud.com/x-gcksjszmqkrjvmvx] has quit [] 01:22 -!- CryptoDavid_ [uid14990@gateway/web/irccloud.com/x-upksqegtlvxskqfk] has joined #bitcoin-wizards 01:25 -!- CryptoDavid_ [uid14990@gateway/web/irccloud.com/x-upksqegtlvxskqfk] has quit [Client Quit] 01:25 -!- wk057 [~wk@unaffiliated/wizkid057] has quit [Read error: Connection reset by peer] 01:26 -!- CryptoDavid_ [uid14990@gateway/web/irccloud.com/x-iqycasdnqhraebdz] has joined #bitcoin-wizards 01:32 -!- CryptoDavid_ [uid14990@gateway/web/irccloud.com/x-iqycasdnqhraebdz] has quit [] 01:32 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 01:33 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards 01:33 -!- CryptoDavid_ [uid14990@gateway/web/irccloud.com/x-hqghmaeagouixnhu] has joined #bitcoin-wizards 01:36 -!- wk057 [~wk@unaffiliated/wizkid057] has joined #bitcoin-wizards 01:43 -!- nijynot [~nijynot@83-233-23-98.cust.bredband2.com] has joined #bitcoin-wizards 01:48 -!- doitux|mob [~doitux|mo@184.75.223.235] has joined #bitcoin-wizards 01:48 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 252 seconds] 01:52 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 268 seconds] 01:53 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 02:01 -!- jonatack_ [~jon@37.173.236.126] has joined #bitcoin-wizards 02:05 -!- jonatack [~jon@37.167.197.45] has quit [Ping timeout: 268 seconds] 02:08 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-wizards 02:32 -!- antanst- [~antanst@62.169.219.213] has joined #bitcoin-wizards 02:33 -!- antanst [~antanst@62.169.219.213] has quit [Ping timeout: 252 seconds] 02:34 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has joined #bitcoin-wizards 02:38 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 265 seconds] 02:38 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-wizards 02:38 -!- stiell [~stian@fsf/member/stiell] has quit [Ping timeout: 276 seconds] 03:13 -!- gtklocker [~gtklocker@snf-9719.ok-kno.grnetcloud.net] has joined #bitcoin-wizards 03:22 -!- TheoStorm [~TheoStorm@host-p8vu8h.cbn1.zeelandnet.nl] has joined #bitcoin-wizards 03:27 -!- simian_za [~simian_za@195.159.29.126] has joined #bitcoin-wizards 03:31 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 268 seconds] 04:00 -!- doitux|mob [~doitux|mo@184.75.223.235] has quit [] 04:01 -!- CryptoDavid_ [uid14990@gateway/web/irccloud.com/x-hqghmaeagouixnhu] has quit [Quit: Connection closed for inactivity] 04:29 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-wizards 04:32 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 268 seconds] 04:34 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 04:40 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 245 seconds] 04:42 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 04:49 -!- khorben1 [~khorben@77.243.177.38] has joined #bitcoin-wizards 05:04 -!- jtimon [~quassel@22.133.134.37.dynamic.jazztel.es] has joined #bitcoin-wizards 05:05 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has quit [Remote host closed the connection] 05:14 -!- wk057 [~wk@unaffiliated/wizkid057] has quit [Ping timeout: 268 seconds] 05:14 -!- Jeremy_Rand_Talo [jeremyra1@gateway/shell/matrix.org/x-mqdgjvpgdkjmytcf] has quit [Read error: Connection reset by peer] 05:15 -!- kewde[m] [kewdematri@gateway/shell/matrix.org/x-ojjnzgbrmxaqvxvr] has quit [Write error: Connection reset by peer] 05:15 -!- azdrianz[m] [azdrianzma@gateway/shell/matrix.org/x-ksmlgjlmgoupckrj] has quit [Remote host closed the connection] 05:15 -!- M7918070_[m] [m7918070ma@gateway/shell/matrix.org/x-gcaeccwwjqkidsip] has quit [Read error: Connection reset by peer] 05:15 -!- dl3br[m] [dlebrechtm@gateway/shell/matrix.org/x-ychupuqjvbceoqse] has quit [Write error: Connection reset by peer] 05:15 -!- hasu[m] [hasumatrix@gateway/shell/matrix.org/x-kskoynojvepazmeh] has quit [Remote host closed the connection] 05:15 -!- hsngrmpf[m] [hsngrmpfma@gateway/shell/matrix.org/x-fvesmgomaqgtibnp] has quit [Remote host closed the connection] 05:15 -!- tomtau[m] [tomtauma1@gateway/shell/matrix.org/x-swhdnwbmhfdvjbqh] has quit [Write error: Connection reset by peer] 05:15 -!- charuto [charutocaf@gateway/shell/matrix.org/x-stpqgvcctbawboqy] has quit [Read error: Connection reset by peer] 05:15 -!- TheFuzzStone[m] [thefuzzsto@gateway/shell/matrix.org/x-fvmnddbnuhmwxtun] has quit [Read error: Connection reset by peer] 05:15 -!- catcow [wavepruner@gateway/shell/matrix.org/x-upidmwllshvtoivg] has quit [Remote host closed the connection] 05:27 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 276 seconds] 05:29 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 05:34 -!- TheoStorm [~TheoStorm@host-p8vu8h.cbn1.zeelandnet.nl] has quit [Remote host closed the connection] 05:34 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 252 seconds] 05:41 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 268 seconds] 05:46 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 05:48 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-wizards 05:55 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 246 seconds] 05:56 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 06:04 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 245 seconds] 06:05 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 06:10 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 245 seconds] 06:19 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 06:20 -!- wk057 [~wk@unaffiliated/wizkid057] has joined #bitcoin-wizards 06:30 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 250 seconds] 06:30 -!- queip_ [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 06:30 -!- queip_ is now known as queip 06:38 -!- wk057 [~wk@unaffiliated/wizkid057] has quit [Ping timeout: 268 seconds] 06:45 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 245 seconds] 06:53 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 07:00 -!- khorben1 [~khorben@77.243.177.38] has quit [] 07:01 -!- Jeremy_Rand_Talo [jeremyra1@gateway/shell/matrix.org/x-dafzpmvcpqybmnyt] has joined #bitcoin-wizards 07:01 -!- dl3br[m] [dlebrechtm@gateway/shell/matrix.org/x-ksiehdrpakmecxop] has joined #bitcoin-wizards 07:01 -!- M7918070_[m] [m7918070ma@gateway/shell/matrix.org/x-gpcrartefaweploh] has joined #bitcoin-wizards 07:01 -!- azdrianz[m] [azdrianzma@gateway/shell/matrix.org/x-ulvdtjlsvxqwusoz] has joined #bitcoin-wizards 07:01 -!- tomtau[m] [tomtauma1@gateway/shell/matrix.org/x-ewpskvanhvhxwiqv] has joined #bitcoin-wizards 07:01 -!- kewde[m] [kewdematri@gateway/shell/matrix.org/x-oekftcqcfpykglzq] has joined #bitcoin-wizards 07:01 -!- TheFuzzStone[m] [thefuzzsto@gateway/shell/matrix.org/x-msjxgtwbzszmahln] has joined #bitcoin-wizards 07:01 -!- catcow [wavepruner@gateway/shell/matrix.org/x-gmqonchxxesxsbwe] has joined #bitcoin-wizards 07:01 -!- charuto [charutocaf@gateway/shell/matrix.org/x-igwlwjuzjloqwswo] has joined #bitcoin-wizards 07:01 -!- hsngrmpf[m] [hsngrmpfma@gateway/shell/matrix.org/x-mhsotsbagtsjgsuq] has joined #bitcoin-wizards 07:01 -!- hasu[m] [hasumatrix@gateway/shell/matrix.org/x-vkpxomdlwnrkheuv] has joined #bitcoin-wizards 07:17 -!- lcb [~lcb@77.243.177.38] has joined #bitcoin-wizards 07:18 -!- TheoStorm [~TheoStorm@host-p8vu8h.cbn1.zeelandnet.nl] has joined #bitcoin-wizards 07:31 -!- stiell [~stian@fsf/member/stiell] has joined #bitcoin-wizards 07:33 -!- hasu[m] [hasumatrix@gateway/shell/matrix.org/x-vkpxomdlwnrkheuv] has quit [Quit: User has been idle for 30+ days.] 07:36 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 252 seconds] 07:40 -!- queip_ [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 07:41 -!- queip_ is now known as queip 07:46 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 276 seconds] 07:47 -!- davterra [~dulyNoded@91.132.136.84] has quit [Ping timeout: 265 seconds] 07:49 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 07:50 -!- davterra [~dulyNoded@2601:603:4f00:63d0:ce:24f0:443d:f011] has joined #bitcoin-wizards 07:50 -!- Socoro [~mix@141.98.103.204] has quit [Ping timeout: 265 seconds] 07:58 -!- davterra [~dulyNoded@2601:603:4f00:63d0:ce:24f0:443d:f011] has quit [Ping timeout: 246 seconds] 08:03 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 268 seconds] 08:08 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 08:20 -!- wk057 [~wk@unaffiliated/wizkid057] has joined #bitcoin-wizards 08:30 -!- wk057 [~wk@unaffiliated/wizkid057] has quit [Read error: Connection reset by peer] 08:36 -!- wk057 [~wk@unaffiliated/wizkid057] has joined #bitcoin-wizards 08:37 -!- TheoStorm [~TheoStorm@host-p8vu8h.cbn1.zeelandnet.nl] has quit [Quit: Leaving] 08:38 -!- wk057 [~wk@unaffiliated/wizkid057] has quit [Read error: Connection reset by peer] 08:42 -!- wk057 [~wk@unaffiliated/wizkid057] has joined #bitcoin-wizards 08:49 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 240 seconds] 08:52 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 09:00 -!- TheoStorm [~TheoStorm@host-p8vu8h.cbn1.zeelandnet.nl] has joined #bitcoin-wizards 09:04 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 265 seconds] 09:05 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 09:11 -!- dr-orlovsky [~dr-orlovs@169.204.90.212.static.wline.lns.sme.cust.swisscom.ch] has quit [Quit: My MacBook has gone to sleep. ZZZzzz...] 09:16 -!- devrando1 [~devrandom@unaffiliated/niftyzero1] has joined #bitcoin-wizards 09:28 -!- wk057 [~wk@unaffiliated/wizkid057] has quit [Read error: Connection reset by peer] 09:31 -!- wk057 [~wk@unaffiliated/wizkid057] has joined #bitcoin-wizards 09:34 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 245 seconds] 09:35 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 09:37 -!- nijynot [~nijynot@83-233-23-98.cust.bredband2.com] has quit [Quit: WeeChat 2.6] 09:37 -!- nijynot [~nijynot@83-233-23-98.cust.bredband2.com] has joined #bitcoin-wizards 09:38 -!- TheoStorm [~TheoStorm@host-p8vu8h.cbn1.zeelandnet.nl] has quit [Remote host closed the connection] 09:50 -!- devrando1 [~devrandom@unaffiliated/niftyzero1] has quit [Ping timeout: 250 seconds] 09:57 -!- queip_ [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 09:57 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 276 seconds] 09:57 -!- queip_ is now known as queip 09:58 -!- lowentropy [~lowentrop@gateway/tor-sasl/lowentropy] has quit [Ping timeout: 260 seconds] 09:59 -!- lowentropy [~lowentrop@gateway/tor-sasl/lowentropy] has joined #bitcoin-wizards 10:00 -!- lcb [~lcb@77.243.177.38] has quit [] 10:03 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 246 seconds] 10:04 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 10:04 -!- nijynot [~nijynot@83-233-23-98.cust.bredband2.com] has quit [Ping timeout: 276 seconds] 10:09 -!- Socoro [~mix@141.98.103.204] has joined #bitcoin-wizards 10:10 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 265 seconds] 10:12 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has joined #bitcoin-wizards 10:12 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 10:17 -!- elsimio [~elsimio@139.28.218.198] has joined #bitcoin-wizards 10:27 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 250 seconds] 10:27 -!- queip_ [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 10:28 -!- queip_ is now known as queip 10:42 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 250 seconds] 10:42 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 10:44 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 10:48 -!- queip_ [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 10:48 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 240 seconds] 10:52 -!- queip_ [~queip@unaffiliated/rezurus] has quit [Ping timeout: 240 seconds] 10:53 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 10:58 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 240 seconds] 11:01 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 11:05 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 245 seconds] 11:07 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 11:10 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 11:11 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has joined #bitcoin-wizards 11:12 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 260 seconds] 11:12 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 246 seconds] 11:13 -!- ghost43_ is now known as ghost43 11:13 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 11:20 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards 11:23 -!- tromp [~tromp@2a02:a210:1585:3200:b1dd:28c9:60ff:6663] has quit [Remote host closed the connection] 11:24 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 268 seconds] 11:24 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds] 11:25 -!- gmaxwell [gmaxwell@wikimedia/KatWalsh/x-0001] has joined #bitcoin-wizards 11:27 < gmaxwell> Is it just me or does the CHECKTEMPLATEVERIFY proposal totally miss the insight of graftroot? -- that a signature is a lot more flexible than a hash, and except for storage considerations, basically strictly superior? 11:28 < gmaxwell> ISTM that proposal would be much better constructed if it pushed the output hash (with optional masking) onto the stack... where it could then be constrained for equality or validated w/ a signature operator that checksigs stuff on the stack. 11:28 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 11:28 < gmaxwell> then it could be used either in a stateless taproot sort of way, or in a more flexible graftroot sort of way. 11:30 -!- DougieBot5000_ [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards 11:31 -!- jeremyrubin [~jr@cpe-75-83-211-236.socal.res.rr.com] has joined #bitcoin-wizards 11:33 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Ping timeout: 240 seconds] 11:36 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 252 seconds] 11:37 < jeremyrubin> Can you expand on what you mean by the insight of graftroot? 11:37 < jeremyrubin> The key benefit of the hash being used is being able to statically verify all possible spends 11:38 < jeremyrubin> Whereas graftroot seems more relevant for delegating control to a post-hoc selected script 11:38 < jeremyrubin> gmaxwell: ^^ 11:39 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 11:40 < jeremyrubin> An OP which pushes the StandardTemplateHash onto the stack would also not have the constexpr restriction that CHECKTEMPLATEVERIFY is designed to support. 11:40 < jeremyrubin> It would be possible to enable more expansive covenants with such an opcode 11:41 < jeremyrubin> Therefore, in the pursuit of the minimal feature to enable the functionality required and not more, especially not to introduce potentially unsafe scripts, CHECKTEMPLATEVERIFY only verifies a constexpr literal matches the computed value. 11:42 < jeremyrubin> I'd be open to making the check of the hash happen via a sighash flag, that had occured to me, but I figured the SIGHASH flags were best left for things which are signatures 11:52 < gmaxwell> jeremyrubin: with a graftroot style construction you can still statically verify admissable spends, and no additional ones could be added without the interaction of the participants. (depending on what signature is used to verify it, the signature could also be a "disguised hash" -- e.g. if it doesn't commit to P). 11:53 < gmaxwell> What specifically do you mean by "unsafe scripts"? 11:59 < gmaxwell> jeremyrubin: as far as masking flags go, one concern I have had with your opcode is that it's extremely specific for its usecase, e.g. binding all outputs and the input count makes it basically impossible to add additional fees. I know there are anti-doubledipping reasons why particular applications may want to cover all fields, but it's a pretty extreme restriction. 12:00 -!- tromp [~tromp@2a02:a210:1585:3200:142d:d239:1e10:f39f] has joined #bitcoin-wizards 12:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards 12:01 < jeremyrubin> gmaxwell: on 11:52, We want to be able to do this without requiring interaction of participants at all. We also want to be able to forbid interaction from novating a contract in certain cases (or at least opt-in/opt-out able) 12:02 -!- ppartyix [~mix@141.98.103.204] has joined #bitcoin-wizards 12:02 < jeremyrubin> 11:53 recursive covenants for example 12:02 < gmaxwell> (and, I think actually if you ever allow 2 inputs, I think it immediately opens up a "spend two outputs at once that allow two inputs, converting half the funds into fees" attack. E.g. I create two idencial coins, A and A' which allow two inputs, so they can get a variable fee input, and each one requires an output of B with all its value. But then an attacker makes a txn that spends both at 12:02 < gmaxwell> once, creating only one B output, and sends the rest of the funds to fees) 12:02 < jeremyrubin> 11:59 It does allow two inputs, if you specify, which can be used for adding fees 12:02 < jeremyrubin> But the superior way is to use CPFP to add fees 12:02 < jeremyrubin> Which package relaying and my mempool work will ameliorate greatly 12:03 < jeremyrubin> gmaxwell: that is specified in the BIP that that is a concern 12:03 < jeremyrubin> Which is why the default case is single-output 12:03 < gmaxwell> jeremyrubin: who is we? that idea that there is something wrong with a recursive covenant is a bad meme which I don't think is seriously held by anyone, -- it's a misunderstanding of my post introducing the term. The whole point of my post was that it's stupid to _create_ immortal covenants, just as it's stupid to throw your private keys away. 12:04 -!- Socoro [~mix@141.98.103.204] has quit [Ping timeout: 265 seconds] 12:05 < gmaxwell> jeremyrubin: I think the pattern I described essentially makes the multi-input usage impossible to use safely. If instead it worked by having each usage of CHECKTEMPLATE 'consume' an output so that no other usage of CHECKTEMPLATE could make use of it, then that vulnerablity goes away, and then I think there is no need to constrain input count at all. 12:05 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 276 seconds] 12:05 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 12:05 < gmaxwell> (aside, thanks for renaming the proposal) 12:06 -!- tromp [~tromp@2a02:a210:1585:3200:142d:d239:1e10:f39f] has quit [Ping timeout: 276 seconds] 12:06 < gmaxwell> s/consume an/consume its/ 12:06 < jeremyrubin> We == people wanting to use this to make non-interactive payments to users? 12:07 < jeremyrubin> So the follow on opcode to introduce to make the reusability concerns go away would be some sort of OP_CHECKINPUT 12:07 < jeremyrubin> so that you're bound to be spent with some other specific output 12:07 < jeremyrubin> Or to add something to check how much total value is being added and reject if out of range 12:08 < jeremyrubin> The checking the fee range one is a bit better as it's more flexible 12:09 < gmaxwell> jeremyrubin: as far as non-interactive goes, graftrooting doesn't necessarily imply interaction. If the signature used doesn't commit to the pubkey, then it can be used as a disguised hash. E.g. I can pick a nums signature and compute the pubkey that makes it valid for a particular message. A third party that doesn't know the nums seed can't distinguish that from a signature. I would have 12:09 < gmaxwell> lobbied heavily to never do taproot and only do graftroot, except an additional signature is space inefficient. 12:09 < jeremyrubin> Hmmm 12:09 < jeremyrubin> Well then isn't there an issue if you do that of not being able to bind multiple values? 12:09 < jeremyrubin> Or are you imaging a graftroot opcode? 12:10 < jeremyrubin> Because OP_IF OP_CTV OP_ELSE OP_CTV OP_ENDIF is a pretty desirable script 12:11 < gmaxwell> If you use a nums signature to treat a signature has a hashcheck then you're stuck with a single value. But it has the nice property that a third party observer can't tell that you did that. Only the first and second party can. It has the downside that it's bigger than a hash. 12:11 < jeremyrubin> If you're using a "local" nums, not a global one, you also lose compressability 12:11 < gmaxwell> Of course, in applications where you might revise the outputs (e.g. using a decrementing CSV sequence like a payment channel), the ability to make revised outputs is probably super useful... it just comes at a cost of interaction. 12:12 < jeremyrubin> OP_IF OP_CTV OP_ELSE OP_CHECKSIG OP_ENDIF 12:12 < jeremyrubin> permits revising, but the defaults have to be spelled out not embedded in the key 12:13 < jeremyrubin> Also permits multiple default branches which is super useful 12:13 < jeremyrubin> Interaction is not realistic for the types of use cases that I designed OP_CTV to support 12:13 < jeremyrubin> E.g., exchanges being able to deposit to thousands of customers during high fee periods 12:14 < jeremyrubin> One bad user can DoS the whole process 12:14 < jeremyrubin> So you can use a NUMS signature, but then you can't add something later right 12:15 < gmaxwell> Right, Nums signature is functionaly the same as a hash however a nums signature is indistinguishable to third parties from people using a real signature. 12:15 < jeremyrubin> that's only true if the parties interact? 12:16 < gmaxwell> No, nums signature doesn't require interaction. 12:16 < jeremyrubin> To communicate the NUMS-ness it does require you to communicate information out-of-band of the chain 12:16 < gmaxwell> And for things like payment pools, interaction is assumed, so real signatures are fine. (I didn't look at your applications yet, so I don't know if you've got payment pools there, perhaps under another name) 12:16 < jeremyrubin> Which I'm counting as an interaction 12:17 < jeremyrubin> I didn't include payment pools as I think they're a bit hard to explain so i focused on more straightforward wins 12:17 < gmaxwell> jeremyrubin: you have to like.. know the exchanges pubkey for any of this to be useful. (in fact you actually have to learn the whole content of the tree of payments ... which can't even be sent in advance) 12:17 < jeremyrubin> Huh? 12:17 < jeremyrubin> What do you mean? 12:17 < gmaxwell> I'm totally fine with leaving that application out of the bip, but I still want it work well. :) 12:18 < jeremyrubin> For CTV or for NUMS-GRAFTROOT 12:18 < gmaxwell> jeremyrubin: I mean if the exchange is going to pay users A, B, C, D .... user D needs to know about that hashtree with A,B,C in it too to know they got paid with CTV. The exchange could tell them the nums 'secret' at the same time. 12:19 < jeremyrubin> Ah correct. The difference is those transactions can be directly broadcast to the mempool/network 12:19 < jeremyrubin> so your assumptions are the same as normal txn relay 12:20 < jeremyrubin> Whereas in order to get this NUMS privacy benefit you have to broadcast it to the user through some new path 12:20 < jeremyrubin> or make it public 12:20 < gmaxwell> Plus they have to interact for the user to provide their own address in the first place. The nums secret is something they only need to learn once for a given counterparty (exchange) 12:20 < gmaxwell> (since the nums value can just be derrived as H(inputs||secret) or the like, no per-payment interaction is needed) 12:20 < jeremyrubin> Wouldn't re-use make it unsafe? or do you imagine tweaking it somehow per-tx 12:20 < jeremyrubin> ok 12:22 < jeremyrubin> I agree there is a benefit to be had in terms of indistinguishability, but I would need to see specific graftroot code and implementation to ensure that the committing to the NUMS signature isn't otherwise leaking information. 12:22 < jeremyrubin> I think also this ends up having to be similar in features to what anyprevout is providing 12:23 < jeremyrubin> because fundamentally it means you aren't signing which TXID 12:26 < jeremyrubin> I think also RE: the NUMS point I like that it is opt-in/out. I just think most people will opt for lower-fees for a well-known NUMS point. 12:27 < jeremyrubin> And if you want to opt-in to better privacy for OP_CTV you can use the musig-alternative script (or a taproot) 12:27 < gmaxwell> It's just strictly more flexible. For the application where there can't be interaction and it has to be set in advance, it doesn't add anything except being indistinguishable from an application where being able to revise is useful. Perhaps the revision isn't all that useful in any case because you could just chain transactions. 12:27 < jeremyrubin> Well it's not strictly more flexible 12:27 < gmaxwell> the downside of chaining to revise is that it's distinguishable and also less efficient. 12:27 < jeremyrubin> OP_CTV is more flexible in allowing multiple alts 12:28 < gmaxwell> jeremyrubin: how so? You can op_if the pubkey to get multiple alternatives in exactly the same way. 12:28 < gmaxwell> nums signature is just a somewhat space inefficienct and potentially denyable hash function. 12:30 < jeremyrubin> I'm assuming graftroot would be implemented like taproot 12:31 < jeremyrubin> I think also the upgrade paths for OP_CTV are desirable. 12:32 < jeremyrubin> As we come up with other things we want to mask in/out we have a straightforward place to put them, whereas I beleive graftroot would be restricted to sighash flags 12:33 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 268 seconds] 12:33 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 12:35 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 12:35 < jeremyrubin> (also, not to be overly practical in the wizards side of discussion, but CTV is designed to be something that could be relatively easy to get through to the community today, even if made redundant in the future. There's a pretty big benefit IMO for helping solve the problems CTV solves ahead of another wave of adoption) 12:36 < gmaxwell> I don't think opcodes that essentially hard code a specific use case are ones that would be easy to get through... they just turn into technical debt if the usecase is eclipsed or turns out to not be popular. 12:37 < jeremyrubin> I don't think it's fair to say CTV is a hard coded specific use case 12:37 < gmaxwell> and a couple lightning specifc things have essentially been shot down for that reason in the past. 12:38 < gmaxwell> jeremyrubin: no, but I don't think it's clear that it doesn't either. Stuff like making it essentialy impossible to add inputs is a really extreme restriction. (yes you can allow multiple inputs, but as I pointed out-- I think it's really hard if not impossible to do that safely due to double dipping) 12:40 < gmaxwell> There is a natural tension between wanting to provide a generic mechenism that has the most usecases, providing something that is simple to implement and review, and proving something that isn't a heinous footgun that is hard/impossible to use safely. 12:41 < jeremyrubin> The multi-input use cases listed are basically limited to wallet vault infrastructure, where you are implementing stuff in a walled garden. Easy enough to prevent key reuse which obviates that concern. 12:41 < gmaxwell> Stuff like CSV and CLTV managed to thread that needle pretty well. 12:42 < jeremyrubin> Also bear in mind I did originally limit it to the single input use case but there was outcry that people wanted a bit more flexibility and that it should be safe enough with this design to permit multiple 12:42 < jeremyrubin> I don't recall specifically but that may have even been yourself at the time ;) 12:42 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 265 seconds] 12:42 < gmaxwell> it's pretty hard to prevent key reuse in general. You essentially need to either avoid any runtime redundancy (creating a single point of failure) or have a consensus system to avoid replay. And still also hope that no one goes and snarfs and address off the blockchain and 'refunds' to it or similar. 12:43 < jeremyrubin> In any case, the multi-input case can be made safer with a chaperone signature for a key known to all participants 12:43 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 12:43 < gmaxwell> I think it's still effecively limited to single input. Or at least, multi-input is only safe to use under a big pile of assumptions. I don't think there is any fundimental reason why this needs to be the case. 12:43 < jeremyrubin> I'm not clear why graftroot is safer here 12:44 < jeremyrubin> Or why anyprevout is safer eitherr 12:44 < jeremyrubin> Also as mentioned the OP_AMOUNTSPENTRANGE type opcode makes this sort of thing safe too 12:44 < gmaxwell> It isn't. Seperate point. The graftroot comment is strictly about flexiblity (/indistinguisability with the more flexible usage) 12:45 < jeremyrubin> Would you like a simultaneous BIP which checks the amount spent is not more than a bound? I think it changes some caching assumptions. 12:46 < gmaxwell> Making multiple inputs safe would need a bit of 'anti-duplication' logic, so that each CTV 'consumes' some outputs so that a seperate CTV couldn't also be satisfied by the same outputs. 12:46 < gmaxwell> I dont like ranging fees as a fix, I think thats kludgy. 12:46 < jeremyrubin> Ok, so you prefer an OP_CHECKINPUT 12:47 < gmaxwell> (and doesn't address the root problem) 12:47 < jeremyrubin> No it doesn't 12:47 < jeremyrubin> because that could be spent under you 12:48 < jeremyrubin> Actually maybe it does? 12:48 < jeremyrubin> Spend to OP_CTV with 0 sats to create input A 12:48 < jeremyrubin> Ah nvm 12:48 < gmaxwell> Yes because thats actually what the application is doing, the fact that it just matches all the outputs is an effort to simplify it... but the real application is along the lines of "this input coin get converted into these outputs". 12:49 < jeremyrubin> Also btw there are underfunded OP_CTV multisig cases that *are safe* to use I think, e.g. kickstarters 12:49 < gmaxwell> which inherently means that two different CTV's ought not be able to double dip by using the same outputs for their satisfaction. In the case where there is only one input, there is no chance of double dipping. 12:50 < jeremyrubin> It would be possible to add the rule that OP_CTV is only defined if it's in the first output, otherwise invalid 12:50 < gmaxwell> jeremyrubin: if the miner can add them up to an overfunded amount, e.g. because non-synchronized users collectively overpay, then they can steal the excess as fees. 12:50 < jeremyrubin> *input 12:50 < jeremyrubin> Would you like that? Then you can't combine OP_CTVs but you can use one with some other coins? 12:50 < gmaxwell> lemme go to lunch and think a bit. 12:50 * gmaxwell bbl lunch 12:50 < jeremyrubin> happy thanksgiving lunch 12:57 < gmaxwell> (I think mostly what I want is something likean OP_CTV that takes a bitmask from the witness about which outputs it's NOT applying to, and the outputs outputs it is applying to are 'spent' and can't be used by any other CTV's bitmask, but I should give that more thought... (I say 'not applying to' so the case of 'all' is a OP_0)) 13:00 -!- elsimio [~elsimio@139.28.218.198] has quit [] 13:00 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 250 seconds] 13:02 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 13:06 -!- jeremyrubin [~jr@cpe-75-83-211-236.socal.res.rr.com] has quit [Ping timeout: 265 seconds] 13:07 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 250 seconds] 13:07 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 13:08 -!- jeremyrubin [~jr@cpe-75-83-211-236.socal.res.rr.com] has joined #bitcoin-wizards 13:09 -!- ppartyix [~mix@141.98.103.204] has quit [Ping timeout: 265 seconds] 13:10 -!- jonatack__ [~jon@37.173.236.126] has joined #bitcoin-wizards 13:11 -!- jonatack_ [~jon@37.173.236.126] has quit [Ping timeout: 245 seconds] 13:22 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 240 seconds] 13:22 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 13:24 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards 13:24 -!- jonatack__ [~jon@37.173.236.126] has quit [Quit: jonatack__] 13:25 -!- jonatack [~jon@37.173.236.126] has joined #bitcoin-wizards 13:26 -!- devrando1 [~devrandom@unaffiliated/niftyzero1] has joined #bitcoin-wizards 13:27 -!- jonatack [~jon@37.173.236.126] has quit [Client Quit] 13:27 -!- jonatack [~jon@37.173.236.126] has joined #bitcoin-wizards 13:29 -!- queip_ [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 13:30 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 276 seconds] 13:30 -!- queip_ is now known as queip 13:42 -!- jeremyrubin [~jr@cpe-75-83-211-236.socal.res.rr.com] has quit [Ping timeout: 240 seconds] 13:47 -!- mcorpgc [~mcorpgc@195.206.169.238] has joined #bitcoin-wizards 13:48 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 276 seconds] 13:48 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 13:55 -!- jeremyrubin [~jr@cpe-75-83-211-236.socal.res.rr.com] has joined #bitcoin-wizards 13:57 < jeremyrubin> The witness so as to prevent malleation? 13:58 < jeremyrubin> (I have kinda spotty reception/lots of thanksgiving stuff so forgive if I'm in and out a bit) 14:01 -!- jonatack_ [~jon@37.170.165.151] has joined #bitcoin-wizards 14:04 < gmaxwell> the witness, so that which outputs will be the matched ones need not be set in advance, but can be set correctly by the txn author. 14:04 -!- jonatack [~jon@37.173.236.126] has quit [Ping timeout: 252 seconds] 14:05 < gmaxwell> In effect, it's just a hint to help the verifier find the matching input(s) rather than having to do an exponential time search. 14:10 -!- tromp [~tromp@2a02:a210:1585:3200:142d:d239:1e10:f39f] has joined #bitcoin-wizards 14:12 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 14:13 -!- jeremyrubin [~jr@cpe-75-83-211-236.socal.res.rr.com] has quit [Ping timeout: 252 seconds] 14:28 -!- dr-orlovsky [~dr-orlovs@2a02:1205:500f:2e90:d08:949d:9420:76eb] has joined #bitcoin-wizards 14:30 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has joined #bitcoin-wizards 14:32 -!- jeremyrubin [~jr@cpe-75-83-211-236.socal.res.rr.com] has joined #bitcoin-wizards 14:34 < jeremyrubin> So one issue there is output malleation. An adversarial miner can re-arrange the outputs, malleating their indexes 14:36 < jeremyrubin> Ah here's a fun rule 14:36 < jeremyrubin> Make OP_CTV commit to the input index! 14:37 < jeremyrubin> By committing to the input index you make some OP_CTVs unspendable together. But you make the reuse safe because the hash commits to the index 14:37 < gmaxwell> hm? two of the same CTV both commiting to 0 would reuse the outputs... 14:38 < gmaxwell> Is miners malleating it particularly a problem? Where it is, you could include required checksig with a key known to all participants. 14:39 < jeremyrubin> gmaxwell: no they wouldn't 14:39 < jeremyrubin> If they both commit to 0 they can't be in the same transaction as they must occupy prevout 0 to be valid 14:39 < gmaxwell> oh INPUT INDEX. 14:40 < jeremyrubin> Yes (one day, we really ought to give unspent outputs, inputs, and outputs some more semantic names) 14:40 < gmaxwell> that is ... kinda weird. athough future softforks that have reason to bind to particular indexes is one of the reasons I argued against BIP69! :) 14:41 < jeremyrubin> I think is addresses your issue with reuse-safety 14:41 < jeremyrubin> Like obviously you could rebind it to another index 14:41 < jeremyrubin> but you can also burn your coins 14:42 < gmaxwell> it would though I think it's almost functionally equivilent to saying there can only be one input using CTV in the trasnsaction. 14:42 < jeremyrubin> No, not at all 14:42 < gmaxwell> (I mean, what would the case ever be for specifying another index, particular if that is the only anti-reuse mechenism?) 14:43 < jeremyrubin> Kickstarter commitments maybe? 14:43 < jeremyrubin> E.g., I CTV to create coins C before time T at index 0 14:43 < jeremyrubin> you can then CTV to create coins C before time T and index 1 14:43 < jeremyrubin> etc. 14:43 < jeremyrubin> Each CTV is under-funded 14:44 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 240 seconds] 14:44 < gmaxwell> and indeed, that also shows a case where 'reuse of an output' is desirable. 14:44 < gmaxwell> But it requires we coordinate, and if we mess up I think we burn coins? 14:44 < gmaxwell> (like if we both pick 0. 14:44 < gmaxwell> ) 14:44 < jeremyrubin> Nope 14:44 < jeremyrubin> hence the "before time T" 14:44 < jeremyrubin> else return to sender 14:44 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 14:45 < gmaxwell> still the coordination is ugly, and I think not essential. 14:45 < jeremyrubin> It does require coordination to not mess up 14:45 < jeremyrubin> It's true that in the under-funded case it works without input index commitments 14:45 < jeremyrubin> Because the CTVs are under-funded 14:45 < jeremyrubin> you actually *want* them to be double spent 14:45 < gmaxwell> I mean that the coordination is purely a side effect of this anti-reuse mechenism, not something fundimental to the application. 14:45 < jeremyrubin> Until you hit saturation 14:46 < jeremyrubin> Correct. 14:46 < jeremyrubin> I guess you can also bind a range of values using taproot 14:46 < jeremyrubin> but that is clunky 14:46 < gmaxwell> You actually want that output to be a SUM of input values, not actually double spent. like if someone adds in a #3 with enough value to fully fund it, you don't want a #4 that adds a bit more to all go to fee. 14:48 < gmaxwell> I think if you're assuming the participants can interact to not clash numbers, thats really close to just saying they can coinjoin to create it and dispense with the CTV. 14:48 < jeremyrubin> The difference being that the commits are on-chain and you know the bounded time before the 'bid' can be withdrawn 14:49 < jeremyrubin> Anyways... that's an aside from the point which is that strictly speaking the commitment to input index does slightly solve the reuse issue 14:49 < jeremyrubin> And it is strictly speaking, possible for multiple indexes to have multiple covenants 14:50 < jeremyrubin> we could also support an ANYINDEX value 14:50 < jeremyrubin> if you don't care 14:51 < jeremyrubin> Also RE coordination, we are already committing to the # of inputs 14:51 < gmaxwell> 'commits are on-chain' -- still leaves a race condition. And as far as withdrawn, maybe not so optimal esp considering that overpayment turns to fees... pretty good incentive to just ignore the withdrawl transaction. :) 14:51 < gmaxwell> jeremyrubin: YES and that is what I've been complaining about from the start: binding additional inputs prevents adding fees directly. 14:52 < jeremyrubin> I think that CPFP is a more robust mechanism 14:52 < jeremyrubin> So I don't think that should be a huge concern 14:52 < gmaxwell> jeremyrubin: as your proposal is right now, the only sensible input count is 1 (because otherwise a copycat input can be double spent), which is also the same as commiting to the index and then everyone commiting a 0. 14:53 < jeremyrubin> Well it's actually not the same 14:53 < jeremyrubin> There are some programmatic use cases where you'd generate templates at different indexes 14:53 < jeremyrubin> Especially around the vault stuff where it's under your control and you want to select from some set of templates 14:53 < gmaxwell> jeremyrubin: CPFP has relay complications, among other limitations. 14:54 < gmaxwell> jeremyrubin: what addresses other people send to is never under your control. 14:54 < jeremyrubin> Not sure what that has to do with it 14:54 < jeremyrubin> CPFP is being improved a lot afaik? Suhas has been working on packagerelay 14:55 < jeremyrubin> And we have the new 1-hop cutout for the mempool 14:55 < jeremyrubin> which fixes some issues related to pinning 14:55 < jeremyrubin> With adding an input to add fee you have to do two transactions; one to set up the correct amount of fee, and then one to include it in the txn. 14:56 < gmaxwell> The CPFP improvements are just taking it from a hack that only works in some cases to a hack that works in more cases. 14:56 < gmaxwell> jeremyrubin: you don't, if you didn't have all these limitations. 14:56 < jeremyrubin> And also it wouldn't work for half the use cases 14:56 < gmaxwell> If the CTV took a witness value that specifies the covered inputs, then additional fee and change could just be provided. 14:56 < jeremyrubin> Because we want to avoid malleating txids 14:56 < jeremyrubin> Malleating the txid is a non option 14:56 < gmaxwell> Why does malleating the txid matter? 14:57 < jeremyrubin> Because you want to use CTV to batch generate channels 14:57 < jeremyrubin> and allow users to blindly request payouts into channels 14:57 < jeremyrubin> You also want to be able to open non-interactive channels, where the counterparty doesn't have a key online 14:58 < jeremyrubin> CTV lets you do all these things, which if you couldn't predict the txid would be not doable 14:58 < gmaxwell> Then effectively the CTV isn't a "template" constrant at all, if you do that, then essneitally it allows the output to only be spent by a _specific_ transaction. 14:59 < jeremyrubin> It is a template, the only template varaible being the specific inputs. 14:59 < gmaxwell> If the txid can't change the "template" is the entire functional part of the transaction. 14:59 < gmaxwell> changing intputs changes the txid. 15:00 < gmaxwell> inputs* 15:00 < jeremyrubin> If you care to suggest a better name please do. 15:01 < jeremyrubin> Also, the idea is that future versions can permit more expansive templates 15:01 < jeremyrubin> By permitting to read non-constexpr templates 15:01 < jeremyrubin> or permitting other variants 15:02 < jeremyrubin> The current BIP just proposes one (which is called StandardTemplate) 15:02 < gmaxwell> as the bip is written it doesn't achieve the goal you've stated here: the txid is malleable (substitute one input for a different one). 15:02 < jeremyrubin> That's incorrect. As noted, if you only use one input that's the only way to acheive non malleability 15:03 < jeremyrubin> It's in the BIP 15:03 < gmaxwell> If it's restricted enough so that this isn't possible, then it only commits to a specific chain of transactions. Which, I can imagine would be useful for some applications, but it is very limited. 15:03 < jeremyrubin> It is insanely useful 15:03 < jeremyrubin> And really not that limited 15:03 < gmaxwell> jeremyrubin: But that isn't so-- e.g. even if there is one input, I could substitue that one input for another equivilent input, and change the txid. 15:03 < jeremyrubin> Yes 15:04 < jeremyrubin> Anyone can pay to any output they like 15:04 < jeremyrubin> Someone can set up a coinbase mirror and pay everyone from coinbase who gets paid just for kindness 15:04 < jeremyrubin> CTV just ensures that you can prove that you will get some specific fund sent your way 15:04 < jeremyrubin> It doesn't prevent people from paying you in the future 15:05 < gmaxwell> I think that the flexibility is just a sham here: as is, this proposal is only useful with a single input, and a fixed set of outputs... and hopefully your fixed set of outputs includes at least one that anyone who'd like to adjust fees can CPFP. 15:07 < gmaxwell> I agree that its useful, but it could be radically simplified to just mandating a single input, and commiting to essentially the whole tx would be equally useful. 15:07 < jeremyrubin> That's what I originally proposed :shrug: 15:07 < jeremyrubin> by the way: https://github.com/JeremyRubin/bips/blob/ctv/bip-ctv.mediawiki#committing-to-the-number-of-inputs 15:08 < jeremyrubin> I think allowing other use cases, with a modicum of flexibility isn't bad 15:08 < jeremyrubin> In fact I have other use cases already which depend on this, around wallet vaults. 15:09 < jeremyrubin> Further, it helps "future proof" the design so that when templates can be stack-computed you can regain tons of flexibility 15:09 < jeremyrubin> Including things like "any number of inputs" 15:12 < gmaxwell> I'd like it to support other use cases, but I think as it doesn't really, the added flexibility without any other safegards is mostly just a footgun. Like you think you can allow two inputs, but really they just lets your coins get burned by a reuse. 15:12 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 15:12 < gmaxwell> The requirement that the txid be non-malleable essentially kills almost any flexibility. 15:13 < jeremyrubin> The txid being non-malleable allows some of the most desirable use cases. 15:13 < gmaxwell> I am not disputing the desirability of that... just pointing out that it kills flexibility. 15:14 < jeremyrubin> I also don't really think it's worth bending over backwards for re-use safety when designing things like... internal custody services 15:14 < jeremyrubin> If you're engineering a custom cold/hot wallet interface, you can avoid reuse in these scenarios easily 15:14 < gmaxwell> Aren't those applications also killed by the ability to cut-through the CTV spend? like if the txn can be spent by CTV _or_ N of N, then that isn't non-malleable. 15:14 < jeremyrubin> Nope 15:14 < jeremyrubin> Because you can do that in the witness 15:15 < jeremyrubin> Ah let me revise 15:15 < jeremyrubin> Yes. if you decide to do a different transaction 15:15 < gmaxwell> Avoiding reuse in a production system is extremely hard. You essentially need a consensus system to do it. You need to either not have backups or secondary backup masters, or have very strong guarentees that they can't come up with old state. 15:15 < jeremyrubin> But then it's incumbent on you to track your channel states and multisig out to something correct 15:15 < gmaxwell> I'm aware of at least one instance where a big bitcoin exchange managed to create a mess by giving out addresses they already gave to other users again... 15:15 < gmaxwell> so I don't buy that it's easy to avoid reuse. 15:16 < jeremyrubin> RE: production reuse, it's actually not difficult in this case because what you can do is tweak your keys basedon the inputs your planning to use 15:16 < jeremyrubin> This gives you provable anti-reuse. 15:16 < gmaxwell> jeremyrubin: I see so in the NofN case you just won't sign that other way unless you are guarenteed to get to recreate your chain of txn there. OK that makes sense to me. 15:16 < jeremyrubin> Well you *could* 15:16 < jeremyrubin> as long as they are equivalent to you 15:16 < gmaxwell> right but if you want to avoid the malleation problems. 15:17 < jeremyrubin> Yes 15:17 < gmaxwell> Gotcha. 15:17 < jeremyrubin> It doesn't force you to have to malleate 15:17 < jeremyrubin> Which is good in taproot 15:17 < jeremyrubin> Because you can hide if it is CTV or Taproot 15:18 < jeremyrubin> Also RE key reuse, we're not talking about keys to users 15:18 < jeremyrubin> We're just talking about writing an API that makes CTV trees and either tweaks leaf nodes with the hash of the inputs or an OP_RETURN random value or something 15:18 < gmaxwell> sorry if you feel like I'm dicking you around on this. I am excited about the prospects. I would really prefer a _general mechenism_ but I guess what I'm learning by talking to you is that we don't actually know what a general mechenism would look like. I thought it could be fully flexible if only it had explicit anti-reuse (or controlled reuse) but since you've pointed out that malleability 15:18 < gmaxwell> is a concern, -- well basically if you care about malleability than I think nothing but a "this coin can be spend only by THIS single input transaction" can work. 15:19 < jeremyrubin> Yeah it basically needs to be very locked down for that reason 15:19 < jeremyrubin> I misled you when I presented COSHV originally 15:19 < jeremyrubin> Was my error 15:19 < jeremyrubin> it was just "hash these outputs" 15:19 < jeremyrubin> Then I realized I had forgotten malleability 15:19 < jeremyrubin> and had to add... a lot of other stuff 15:20 < jeremyrubin> I think with the current CTV mechanism, loosening the restriction on constexpr ness + OP_CAT would add a *lot* of this flexibility back in 15:21 < jeremyrubin> (OP_CAT or OP_SUBSTR & friends) 15:21 < gmaxwell> For the application I care about (payment pools), the totally locked down case is fine. (though I think being able to graftroot substitute would be somewhat better) -- because in that application the CTV (check transaction verify!) is really only just guarentting a backup backout state. 15:21 < jeremyrubin> So it can be made fully graftroot compatible in the future if it's in a taproot leafd 15:22 < gmaxwell> it's unclear to me how viable programmatically constructing templates really is... I guess I'd need to see concrete examples to be confident that this worked, and wouldn't constantly get messed up by the absense of opcodes or where performing some check is really absurdly expensive. 15:22 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 250 seconds] 15:22 < jeremyrubin> You also can emulate graftroot by permitting a signed hash? 15:22 < jeremyrubin> You can look at my demo-quality code for sendmanycompacted 15:23 < jeremyrubin> You essentially build up the tree bottom up 15:23 < gmaxwell> Well I still think I like an operation that PUSHs the CTV hash... which then you'd have the freedom of comparing for equality OR checking with a checksigfromstack. 15:23 < jeremyrubin> I also recommend watching my scaling bitcoin talk 15:23 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 15:24 < gmaxwell> Other than some 'constness' goal, I don't see any advantage to the VERIFY construction. (and I don't think the constness is actually something anyone needs: yes, it means some footgun uses aren't possible, but you can always burn your coins) 15:24 < jeremyrubin> It's there to prevent any sort of "non enumerable"covenants 15:24 < gmaxwell> Who cares? 15:24 < gmaxwell> I can post my private keys online, or throw my coins away. 15:24 < jeremyrubin> Well, everyone I've talked to about this beleives, you? 15:25 < jeremyrubin> So maybe you should make your views on some of these issues a bit more well known 15:25 < jeremyrubin> :) 15:26 < jeremyrubin> I'd be happy to discard the constness rule if people check it over and determine that permitting these sorts of things are fully safe 15:27 < gmaxwell> This is some weird cult thing and I'm confused by it. I think I said earlier: I think it would be idiotic to subject your own coins to a perpetual encumberance -- effectively you're burning them if you do that. And I think it's funny to imagine what kind of silly ways people could come up with to do that... but anyone can burn coins at any time for any reason they want. 15:27 < gmaxwell> I'm not sure how to be any more clear on that. 15:27 < jeremyrubin> Maybe write one the mailing list that you think the constexpr rule can be safely dropped 15:28 < jeremyrubin> I would love that as it also solves Russel's concern about parsing 15:28 < gmaxwell> I'm not even completely sure that there isn't a way to get a perpetual encumberance today (or that one isn't created by tapscript)... we just don't know how currently. I've shown a couple ways in the past that the original bitcoin rules allowed for it... and how a couple rules (like a checksigfromstack) create one. :) 15:28 < gmaxwell> OK. well I'm not on the list but I could do that. 15:29 < jeremyrubin> Why not? Too much noise these days? 15:29 < gmaxwell> yeah, it's very high SNR, and interacting with some hostile people that show up there (like voskuil) just makes my life suck and I'd rather not have anything to do with bitcoin tech than deal with more of that crap. 15:30 < gmaxwell> er very LOW SNR 15:30 < gmaxwell> HIGH NSR. :P 15:30 < gmaxwell> same reason I'm mostly not in this channel anymore. (just came in here because I knew I could get your attention here, or at least someone else who might care) 15:31 < jeremyrubin> Ah yeah. Because of the holidays I only found out you commented here because of amiti pinging me :) 15:31 < jeremyrubin> But it's good that others can look through this discussion 15:33 < jeremyrubin> I think the main motivating factor for the constexpr rule is that it lessens the review burden (opcode introduces *provably*) fewer features, so we don't worry about what it may enable or not. But if we're on-board for "if you want to waste your coins, do it" I agree it can be removed. 15:33 < gmaxwell> anyways. I think the constexpr can go, and that it could basically be an opcode that sticks the hash of the whole txn except input-txids, and only one input.. onto the stack. And then you're free to check that hash however you want (equality, or a future checksigfromstack strike me as the most useful). ... and future versions that are more relaxed-- if we can manage to come up with an actually 15:33 < gmaxwell> general mechenism which adds more applications and isn't an automatic footgun-- could just be different opcodes. 15:34 < gmaxwell> yes but the constexpr thing also implies a very "unscriptlike" evaluation constraint, that makes pretty strong assumptions about how the verifier is programmed. So it's not free, I think. 15:34 < jeremyrubin> Only one input breaks some vault use cases so I'd prefer to keep it. 15:35 < gmaxwell> and it comes at the cost of breaking the ability to use the opcode with signatures for a grafty construction. Maybe that isn't that big a loss, because you could key-path spend to cut past to a different set of outputs. I guess I should contemplate that some more before being convinced that the loss of being able to sign for it matters. 15:35 < gmaxwell> I'm really dubious that those are safe. Are they described in the BIP? 15:36 < jeremyrubin> I don't care too much about the VERIFY vs PUSH semantics.. can you come up with a concrete example of why it would be worth the extra opcode to check equals? The checksigfromstack works with either verify or push 15:37 < jeremyrubin> I'm in the process of spec'ing them more tightly, but there is a diagram here: https://github.com/JeremyRubin/bips/blob/ctv/bip-ctv.mediawiki#wallet-vaults 15:37 < jeremyrubin> It's doable with pre-signed txns today 15:38 < jeremyrubin> I think kanzure has some vault work that is similar, that would be made better with CTV 15:38 < jeremyrubin> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017229.html 15:39 < gmaxwell> The verify requires you put an extra 32-bytes in the witness. Otherwise I believe the only other difference is that you can't construct a "IF NOT CTV", which ... it's not an obviously useful construct to me but also there is no reason why it shouldn't be possible to create. For things like time (e.g. CLTV) constraints it's important for consensus reason that the match not be invertable, which 15:39 < gmaxwell> is why they're forced through the one-way latching nlocktime. 15:40 < gmaxwell> Because the CTV constraints the whole transaction a NOT-CTV isn't too useful (e.g. bypass by just using a different nlocktime), if CTV constrained less it might be useful. 15:41 < jeremyrubin> huh? Why does verify require extra data in witness 15:42 < jeremyrubin> scriptPubKey: <32 bytes> OP_CTV 15:42 < jeremyrubin> scriptSig: 15:42 < jeremyrubin> witness stack: 15:42 < gmaxwell> like if I want to checksig from stack, my witness would push the CTV hash and the signature, and the witnessprogram would verify the signature and run CTV on the hash. But a PushTV the witness would just be the signature. 15:42 < gmaxwell> and the witness program would push the hash then validate the signature on it. 15:44 < gmaxwell> (also we prefer 'validate' like checksigs, or at least ones with "designated failure inputs", due to batch validation-- but that doesn't apply for CTV) 15:45 < jeremyrubin> hm. let me think on that one. If you have CheckSigFromStack you might do some other things differently too 15:46 < jeremyrubin> I also generally think we could make the precomputedtxdata always accessible by special opcodes in a new tapscript version 15:46 < gmaxwell> I really hope it gets CheckSigFromStack... it's surprisingly useful and also absurdly simple. 15:47 < jeremyrubin> I don't think anyone is proposing it presently? 15:47 < gmaxwell> it was at one point just part of an early tapscript proposal but got stripped because it can be easily added later with a OP_SUCCESS 15:48 < gmaxwell> the whole taproot thing seems to have been a circus of removing functionality to get it done fast, then dropping it on the floor because half the interesting stuff got taken out. :P 15:48 < gmaxwell> (as was reenabling size limited versions of many of the disabled opcodes, like elements) 15:49 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 265 seconds] 15:50 < jeremyrubin> :shrug: 15:50 < jeremyrubin> bitcoin is hard 15:50 < jeremyrubin> maybe someone will pick it up 15:53 < gmaxwell> Yep. Oh I'm sure it'll be picked up, I think people are just waiting for taproot to make more progress. 15:53 < gmaxwell> in particular it should copy the taproot signature type ... and stuff like pubkey styles have been changing soooo. 15:54 * gmaxwell bbl 15:57 * jeremyrubin afk 16:00 -!- mcorpgc [~mcorpgc@195.206.169.238] has quit [] 16:00 -!- marcoagner [~user@bl11-16-162.dsl.telepac.pt] has quit [Ping timeout: 246 seconds] 16:11 -!- tromp [~tromp@2a02:a210:1585:3200:142d:d239:1e10:f39f] has quit [Remote host closed the connection] 16:12 -!- jeremyrubin [~jr@cpe-75-83-211-236.socal.res.rr.com] has quit [Ping timeout: 240 seconds] 16:17 -!- jeremyrubin [~jr@cpe-75-83-211-236.socal.res.rr.com] has joined #bitcoin-wizards 16:17 -!- Usurp [~Usurp@139.28.218.198] has joined #bitcoin-wizards 16:24 -!- queip_ [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 16:24 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 240 seconds] 16:24 -!- queip_ is now known as queip 16:31 -!- jeremyrubin [~jr@cpe-75-83-211-236.socal.res.rr.com] has quit [Ping timeout: 265 seconds] 16:51 -!- tromp [~tromp@2a02:a210:1585:3200:142d:d239:1e10:f39f] has joined #bitcoin-wizards 16:56 -!- tromp [~tromp@2a02:a210:1585:3200:142d:d239:1e10:f39f] has quit [Ping timeout: 246 seconds] 17:15 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 250 seconds] 17:17 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 17:24 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 250 seconds] 17:26 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 17:34 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [] 17:53 -!- devrando1 [~devrandom@unaffiliated/niftyzero1] has quit [Ping timeout: 250 seconds] 18:00 -!- TheoStorm [~TheoStorm@host-p8vu8h.cbn1.zeelandnet.nl] has joined #bitcoin-wizards 18:13 -!- devrando1 [~devrandom@unaffiliated/niftyzero1] has joined #bitcoin-wizards 18:24 -!- devrando1 [~devrandom@unaffiliated/niftyzero1] has quit [Ping timeout: 250 seconds] 18:24 -!- dr-orlovsky [~dr-orlovs@2a02:1205:500f:2e90:d08:949d:9420:76eb] has quit [Quit: My MacBook has gone to sleep. ZZZzzz...] 18:27 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 240 seconds] 18:54 -!- DougieBot5000_ is now known as DougieBot5000 18:56 -!- Belkaar_ [~Belkaar@xdsl-78-35-200-244.nc.de] has quit [Ping timeout: 240 seconds] 18:57 -!- Belkaar [~Belkaar@xdsl-85-197-43-198.nc.de] has joined #bitcoin-wizards 18:57 -!- Belkaar [~Belkaar@xdsl-85-197-43-198.nc.de] has quit [Changing host] 18:57 -!- Belkaar [~Belkaar@unaffiliated/belkaar] has joined #bitcoin-wizards 19:00 -!- Usurp [~Usurp@139.28.218.198] has quit [] 19:06 -!- TheoStorm [~TheoStorm@host-p8vu8h.cbn1.zeelandnet.nl] has quit [Quit: Leaving] 19:16 -!- jeremyrubin [~jr@cpe-75-83-211-236.socal.res.rr.com] has joined #bitcoin-wizards 19:17 -!- RD [~RD@139.28.218.198] has joined #bitcoin-wizards 19:17 -!- RD is now known as Guest20380 19:19 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has quit [Remote host closed the connection] 19:29 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds] 19:31 -!- jeremyrubin [~jr@cpe-75-83-211-236.socal.res.rr.com] has quit [Ping timeout: 265 seconds] 19:32 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 265 seconds] 19:32 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 19:33 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-wizards 20:17 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 20:32 -!- jtimon [~quassel@22.133.134.37.dynamic.jazztel.es] has quit [Remote host closed the connection] 20:56 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 245 seconds] 21:08 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 240 seconds] 21:08 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 21:15 -!- _whitelogger [~whitelogg@uruz.whitequark.org] has quit [Remote host closed the connection] 21:16 -!- _whitelogger [~whitelogg@uruz.whitequark.org] has joined #bitcoin-wizards 21:34 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 240 seconds] 21:36 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 21:37 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 21:37 -!- superkuh [~superkuh@unaffiliated/superkuh] has quit [Quit: the neuronal action potential is an electrical manipulation of reversible abrupt phase changes in the lipid bilayer] 21:52 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 250 seconds] 21:53 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 22:00 -!- Guest20380 [~RD@139.28.218.198] has quit [] 22:21 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 22:36 -!- tromp [~tromp@2a02:a210:1585:3200:b0b8:dd4a:6a28:be4d] has joined #bitcoin-wizards 22:47 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 265 seconds] 22:47 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards 22:58 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has joined #bitcoin-wizards 23:03 -!- tromp [~tromp@2a02:a210:1585:3200:b0b8:dd4a:6a28:be4d] has quit [Remote host closed the connection] 23:12 -!- rh0nj [~rh0nj@88.99.167.175] has quit [Remote host closed the connection] 23:13 -!- rh0nj [~rh0nj@88.99.167.175] has joined #bitcoin-wizards 23:15 -!- James_F1 [~James_F@89.238.178.75] has joined #bitcoin-wizards 23:16 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-wizards 23:17 -!- tromp [~tromp@2a02:a210:1585:3200:b0b8:dd4a:6a28:be4d] has joined #bitcoin-wizards 23:31 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 240 seconds] 23:33 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-wizards --- Log closed Fri Nov 29 00:00:22 2019