stutxo 20:23:44
heyo
kevkevin 20:23:49
hi
← Guest85 has left (Client Quit)
bytes1440000 20:28:35
hi
→ Guest19 has joined
kevkevin 20:28:47
hi
Guest19 20:28:55
hello!
bytes1440000 20:29:16
Will start in a few minutes. Maybe a few others might also join.
→ jonatack has joined
kevkevin 20:30:59
sounds good to me!
→ Guest42 has joined
→ monlovesmango has joined
← jonatack has left (Ping timeout: 245 seconds)
← Guest42 has left (Client Quit)
kevkevin 20:37:57
are we good to start?
bytes1440000 20:38:10
Yes. Hi today we will go through BIP 119 and broadcast a CTV transaction on signet.
ⓘ Guest19 is now known as Pupusas42
kevkevin 20:38:43
sounds fun!
bytes1440000 20:38:45
So lets start with the BIP: https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki
→ Guest19 has joined
bytes1440000 20:39:43
BIP 119 or CTV is a proposed soft fork which would allow the users to restrict UTXOs in a way that they can only be spent to committed address, amount etc.
→ stutxo78 has joined
bytes1440000 20:40:32
In total 8 things are used for the commitment and generating CTV hash
nVersion (4 bytes)
nLockTime (4 bytes)
scriptSigs hash (32 bytes, if any)
Input count (4 bytes)
Sequences hash (32 bytes)
Output count (4 bytes)
Outputs hash (32 bytes)
Input index (4 bytes)
This hash should match while spending the transaction else it will fail
That is the basic definition of CTV and its pretty simple compared to other covenant proposals
kevkevin 20:42:15
by this hash you mean hash(all those bytes together)?
bytes1440000 20:42:23
yes
← Pupusas42 has left (Ping timeout: 250 seconds)
← stutxo has left (Ping timeout: 250 seconds)
kevkevin 20:42:49
bytes1440000 ok ty
← stutxo78 has left (Client Quit)
→ stutxo has joined
bytes1440000 20:43:16
Why would we want to do this? So the motivation is to improve the UX in contracts and scaling
We use pre-signed transactions in most bitcoin contracts
They increase the level of interaction required among users
There are DoS vectors and other issues
With covenanted UTXO we can get rid off these problems
reduce the interaction required
There are several use cases and some of them are listed here: https://en.bitcoin.it/wiki/Covenants_Uses
monlovesmango 20:45:43
is it fair to say all functionality enabled by presigned txs is also enabled by ctv?
bytes1440000 20:45:57
yes
 i think we can do almost everything ctv does
using pre-signed txs but in a worse way
vaults, pools etc. are possible and already built using pre-signed txs
Guest19 20:47:00
in 5 year old terms, CTV keeps track of how many inputs + outputs, and predefines what they should look like by hashing?
kevkevin 20:47:00
From what I understand that is why there is multiple types of ark implementations
stutxo 20:47:01
the biggest downside to pre-signed tx is for some use cases there is a trusted setup where someone has to delete at least one key to emulate ctv correctly
monlovesmango 20:47:06
is there anything that ctv enables that goes beyond presigned txs (somewhat ignoring DoS vectors and other issues)
?
bytes1440000 20:47:45
Gurst19: yes and it doesnt commit to inputs but only number of inputs
monlovesmango 20:47:51
Guest19: yes except it does not define what the input looks like (just number of inputs)
bytes1440000 20:48:21
monlovesmango: No
bytes1440000 20:49:31
There is some python pseudocode in the BIP which shows how CTV works at basic level but you can see the actual implementation in the pull request open in core repo.
What else is mentioned in the BIP?
https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#rationale
Rationale section is important
kevkevin 20:50:35
bytes1440000 one thing I saw mentioned in the BIP is decent pathways for upgrading OP_CTV in the future
bytes1440000 20:50:40
which shares the reason for commiting to different things
kevkevin: yes
Most probably it would be TXHASH in future
but difficult to predict
There was recently some discussion about use of scriptsigs with CTV: https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591
Some developers do not like this behaviour and find it hacky
kevkevin 20:52:35
I saw this post and was wondering what everyone thought about it, basically a footgun where you send the wrong amount either too much or too little and lose some satoshis
https://delvingbitcoin.org/t/understanding-and-mitigating-a-op-ctv-footgun-the-unsatisfiable-utxo/18...
bytes1440000 20:53:24
kevkevin: I dont agree with Chris
→ Guest47 has joined
← Guest19 has left (Ping timeout: 250 seconds)
bytes1440000 20:54:03
I think these things can be avoided by application developers
https://delvingbitcoin.org/t/understanding-and-mitigating-a-op-ctv-footgun-the-unsatisfiable-utxo/18...
This was my response about watchtowers
kevkevin 20:54:31
bytes1440000 that is fair, I do think that coins can already be lost on accident already using script, just found it interesting
bytes1440000 20:54:38
yeah
→ jonatack has joined
monlovesmango 20:55:08
bytes1440000: I think its hacky but kinda cool
bytes1440000 20:55:09
its possible to burn bitcoin accidentally by using op_return
monlovesmango: agree
did we miss anything important from the BIP?
kevkevin 20:56:31
is there any opinion on OP_TEMPLATEHASH? It seems to be similar/inspired by OP_CTV but restricted to tapscript
https://github.com/instagibbs/bips/blob/bip_op_templatehash/bip-templatehash.md
bytes1440000 20:56:36
This is the simplest BIP I have ever read that is proposed for soft fork
kevkevin: Some developers prefer TEMPLATEHASH
But I dont like it being restricted to only taproot
kevkevin 20:57:33
bytes1440000 agreed this BIP is simple and straightforward and enables lots of improvements to bitcoin script
kevkevin 20:58:35
bytes1440000 are there reasons for not wanting it to be only restricted to taproot? I think the rationale for restriction is to reduce the surface area by leaving legacy scripts alone
monlovesmango 20:59:12
templatehash doesn't have the scriptSig hack right?
← jonatack has left (Ping timeout: 252 seconds)
bytes1440000 20:59:25
I think we should allow covenants in all scripts and let users decide
monlovesmango: yes
I was planning to use my electrum plugin for today's demo but it has some bug that i need to fix
its not generating the corrrect transactions
https://gitlab.com/1440000bytes/sandwich
→ Guest75 has joined
bytes1440000 21:00:17
So we will use CTV playground by ursus
https://github.com/ursuscamp/ctv
You can run this locally and access it in browser: localhost:5555
bytes1440000 21:04:36
https://mempool.space/signet/tx/674723f7012a8c22340a9b01ff89cdb78e4a2377ec115627c43dfdeb3262b254
You will have to enter bitcoin address and amount for a simple lock
Then send sats to CTV address generated by playground
It will return the unlock tx which spends CTV UTXO
bytes1440000 21:07:29
Link to read about earlier workshops: https://utxos.org/workshops/
Let me know if you have any questions
← Guest75 has left (Quit: Client closed)
bytes1440000 21:08:23
Another post to test CTV on regtest: https://bitcoindocs.org/notes/newbie-guide-to-check-template-verify-op-ctv
kevkevin 21:09:29
Are you going to create the CTV address with the simple lock and send these fund there?
bytes1440000 21:11:15
This is CTV address: tb1qkhw0gu04y7hn0hvcjnq87dkwcp24ynd667cxksclt7mhfz4z4mkqdtscxs
kevkevin 21:14:13
gotcha
kevkevin 21:15:31
this was awesome, thanks bytes1440000
monlovesmango 21:15:59
are you going to spend funds from the ctv address?
kevkevin 21:16:21
oh yea that would be good to see aswell
bytes1440000 21:16:30
yes i have broadcasted the tx but its not confirmed yet
let me share the raw transaction
0100000000010154b26232ebfd3dc4275611ec77234a8eb7cd89ff019b0a34228c2a01f723476700000000000000000001e83f0f00000000001600140439b5bd6752f904661b6fcecd1a7e7006ace60301222037f228899e764d63101c4157fc968c2add5b67113c2515b59704896e36c7bde3b300000000
you would need bitcoin inquisition to broadcast these transactions on signet
and addnode inquisition.bitcoin-signet.net
monlovesmango 21:19:07
nice thanks
bytes1440000 21:19:26
thank you everyone for joining the channel. we might do another workshop next week. maybe cover the basics of CSFS and test it.
monlovesmango 21:19:56
sounds good thanks!
kevkevin 21:21:00
thank you!