--- Log opened Mon Sep 21 00:00:24 2020 00:24 -!- peter_ [~peter@185.114.3.24] has joined #rust-bitcoin 01:26 -!- darosior3 [~darosior@194.36.189.246] has joined #rust-bitcoin 01:27 -!- darosior [~darosior@194.36.189.246] has quit [Ping timeout: 256 seconds] 01:54 -!- darosior3 [~darosior@194.36.189.246] has quit [Read error: Connection reset by peer] 01:54 -!- darosior3 [~darosior@194.36.189.246] has joined #rust-bitcoin 02:22 -!- darosior3 [~darosior@194.36.189.246] has quit [Quit: ya vps net disruption] 02:23 -!- darosior3 [~darosior@194.36.189.246] has joined #rust-bitcoin 02:51 -!- jaspal [2ac882cd@42-200-130-205.static.imsbiz.com] has joined #rust-bitcoin 02:53 < jaspal> Hi guys 02:54 < jaspal> I was trying to understand bitcoin digital signatures, their implementation and usage 02:55 < jaspal> For now, what I have understood is that we have a unsigned raw transaction for an input, say: 010000000194d612f5ec40d483ed82bf346d8f08961d61fdf2d6b9804d7731e608d816e533000000001600149590528354a94bee0a9f37672e204255d2ee6fc1fdffffff0110270000000000001600143b36ddb4d9f75f4010450b25a8952a6725981bfb00000000 02:55 < jaspal> I create a digital signature for this unsigned raw transaction. 02:56 < jaspal> Using ECDSA (in hex) the signature came out to be: 30440220a2d8aeb26062c84c8f8e57a77612f2ba7f8cb1617ba831c7da14b366c960e81f022060aaa6ae08956a0ab9d870c7397b8f5cfa55e6253ed369df6bd65fc3a9136dc7 ...but what I fail to understand is where to go from here? How to proceed to use these two entities to create a signed transaction and successfully submit it? 02:59 -!- darosior3 [~darosior@194.36.189.246] has quit [Quit: ya vps net disruption] 02:59 -!- darosior3 [~darosior@194.36.189.246] has joined #rust-bitcoin 03:01 -!- darosior3 [~darosior@194.36.189.246] has quit [Client Quit] 03:01 -!- darosior3 [~darosior@194.36.189.246] has joined #rust-bitcoin 03:04 -!- darosior3 is now known as darosior 03:22 < sgeisler> Hi jaspal, it all depends on what kind of output you are spending. In your case it seems to be a p2wpkh output that you use as input. In that case what you need to do is construct the witness stack using the signature as the first and the public key as the second element. You seem to have put something looking like a script pub key into the script sig field of your transaction, which is invalid afaik. 03:25 < sgeisler> You also need to be careful when constructing the hash to sign for SegWit tx, as the algorithm is another one than for old style transactions (see BIP-143). 03:26 < sgeisler> A nice way to look into your transactions is `hal`btw, a little utility by stevenroose. https://github.com/stevenroose/hal/ 03:36 < jaspal> Hey man that's really helpful!!! 03:36 < jaspal> You're right I put the script pubkey instead of the script sig 03:42 -!- jaspal [2ac882cd@42-200-130-205.static.imsbiz.com] has quit [Remote host closed the connection] 04:18 -!- Ramon38Beier [~Ramon38Be@static.57.1.216.95.clients.your-server.de] has joined #rust-bitcoin 04:51 < sgeisler> jaspal: yeah, the thing is that there is no script sig in p2wpkh inputs. E.g. take a look at the transaction that actually spent the input you tried to spend in your tx using `hal tx decode ` 04:51 < sgeisler> (you can get the hex tx from here for example: https://blockstream.info/testnet/api/tx/69990be1df99961aa4abb1a58b5e6940753a30a3c6a1e741c67ae7beb8ae989b/hex) 04:53 < sgeisler> You see that the input has an empty `script_sig`, but the sig+pubkey in the witness stack: https://gist.github.com/sgeisler/b3ec0f0937ba3027e6d8b05b3b76e86f#file-gistfile1-txt-L11-L24 04:55 -!- Ramon38Beier [~Ramon38Be@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 272 seconds] 05:07 -!- vindard [~vindard@190.83.165.233] has quit [Remote host closed the connection] 05:08 -!- vindard [~vindard@190.83.165.233] has joined #rust-bitcoin 06:13 -!- vindard [~vindard@190.83.165.233] has quit [Ping timeout: 240 seconds] 06:16 -!- vindard [~vindard@190.83.165.233] has joined #rust-bitcoin 08:55 < BlueMatt> and that's hard because we can't substract from a channel opening <-- sure we can! you just have to open a new channel. 08:55 < BlueMatt> the old one can time out. 08:56 < BlueMatt> as for your other notes, I'm not sure I really understood your question? 08:56 < BlueMatt> I presume the context is anchor? I think thats why im confused 09:15 < ariard> BlueMatt: yes the context is anchor 09:15 < ariard> BlueMatt: the main point is you need to save utxo to feed the anchor output CPFP 09:16 < BlueMatt> right, we have to kick that to users 09:16 < ariard> BlueMatt: and my question is a) asking the utxo interface to save one on its own or b) substracting this utxo from any funding tx 09:17 < ariard> but we can't do this for sure for single-funded channel so better to let that to kick that to users 09:17 < BlueMatt> you mean updating the funding interface to always require two outputs instead of one? 09:17 < BlueMatt> i feel like that boxes users into a less-effecient utxo scheme 09:18 < ariard> and how much do we provision is a good question, ideally something like max_htlc_value_in_flight because that's the biggest risk 09:18 < ariard> right that box users in a less efficient scheme, but the notion of provisioned utxo you never touch to is weird too 09:18 < ariard> at least with Core you can lock utxos 09:20 < BlueMatt> right, especially for the "lightning-only wallet" use-case 09:21 < BlueMatt> which i anticipate is what folks want 09:21 < BlueMatt> but, like, you can also under-provision, have one utxo available for two channels may be totally reasonable (even if not ideal) 09:21 < BlueMatt> so forcing users to generate one per channel sucks. 09:21 < ariard> yes I guess people will be on fractional reserve 09:22 < ariard> it's not economically bearable to have 100% of your `max_htlc_value_in_flight` per-channel never used 09:23 < ariard> said differently there is a wrinkle if a counterparty observe mempool congestion and guess you don't have any bumping utxo to timeout/claim HTLC 09:23 < BlueMatt> right 09:23 < BlueMatt> its not great security-wise... 09:24 < ariard> you see my point, this fee model is weird too 09:26 < BlueMatt> yea, i mean i dont know what the answer is aside from just telling users to always have utxos available and bake that into the api 09:26 < BlueMatt> us doing our own utxo ownership doesn't really make it any easier 09:26 < ariard> if you provision node-wise for 30% of global locked value, that's okay if you don't have a coalition of your counterparties > 30% 09:27 < BlueMatt> ariard: do note that https://github.com/rust-bitcoin/rust-lightning/pull/715 blocks 649, so i dont want to hold it up any more than we have to (I'll respond to your comments after lunch) 09:27 < BlueMatt> just a general note 09:27 < ariard> us doing utxo ownership wouldn't work as it may prevent to open channel at all if you don't have 120% available 09:28 < ariard> BlueMatt: i'm fine I can take the clean disjunctive outpoints on one of my branch 09:31 < BlueMatt> hmm? right i was referencing your earlier suggestion to require two outputs on the funding tx 09:31 < ariard> ah well let's discuss after lunch I still have few tests to fix :) 12:45 -!- kallewoof [~quassel@240d:1a:759:6000:a7b1:451a:8874:e1ac] has quit [Quit: No Ping reply in 180 seconds.] 12:47 -!- kallewoof [~quassel@240d:1a:759:6000:a7b1:451a:8874:e1ac] has joined #rust-bitcoin 12:51 -!- kallewoof [~quassel@240d:1a:759:6000:a7b1:451a:8874:e1ac] has quit [Client Quit] 12:53 -!- kallewoof [~quassel@240d:1a:759:6000:a7b1:451a:8874:e1ac] has joined #rust-bitcoin 13:56 -!- peter_ [~peter@185.114.3.24] has quit [Ping timeout: 240 seconds] 18:37 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has quit [Ping timeout: 260 seconds] 18:48 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #rust-bitcoin 21:37 -!- vindard [~vindard@190.83.165.233] has quit [Ping timeout: 272 seconds] 21:48 -!- vindard [~vindard@190.83.165.233] has joined #rust-bitcoin 23:39 -!- reallll [~belcher@unaffiliated/belcher] has joined #rust-bitcoin 23:43 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Ping timeout: 264 seconds] 23:53 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin 23:54 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds] 23:59 -!- reallll is now known as belcher --- Log closed Tue Sep 22 00:00:25 2020