--- Log opened Fri Jan 24 00:00:19 2020 01:39 -!- jonatack [~jon@213.152.161.138] has quit [Ping timeout: 265 seconds] 02:14 -!- wumpus [~ircclient@pdpc/supporter/professional/wumpus] has quit [Read error: Connection reset by peer] 02:41 -!- wumpus [~ircclient@pdpc/supporter/professional/wumpus] has joined #rust-bitcoin 02:51 -!- jonatack [~jon@109.202.107.15] has joined #rust-bitcoin 03:04 -!- Anastasia23Stros [~Anastasia@ns334669.ip-5-196-64.eu] has joined #rust-bitcoin 03:45 < stevenroose> > Why stop at splitting the EC point from the compressedness boolean? Why not split all the bytes apart and let users decide when they should be brought together? 03:45 < stevenroose> andytoshi: troll much? :'D 03:47 < stevenroose> We all know an EC pubkey is a point on the curve and the boolean is not needed to represent that point. I'm sure you agree the boolean being there is not needed, but just a situational workaround. 03:48 < stevenroose> I don't have that strong feelings against it, though. 05:25 -!- jonatack [~jon@109.202.107.15] has quit [Quit: jonatack] 07:32 -!- notmandatory [~textual@cpe-76-169-37-102.socal.res.rr.com] has joined #rust-bitcoin 07:38 -!- notmandatory [~textual@cpe-76-169-37-102.socal.res.rr.com] has quit [Quit: notmandatory] 07:48 -!- notmandatory [~textual@cpe-76-169-37-102.socal.res.rr.com] has joined #rust-bitcoin 08:08 < dr-orlovsky> dpc: & stevenroose: as follow-up to the yesterday script discussion: here is a gist illustrating my idea of a nested bitcoin script typing system: 08:12 -!- Anastasia23Stros [~Anastasia@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 260 seconds] 08:23 -!- notmandatory [~textual@cpe-76-169-37-102.socal.res.rr.com] has quit [Quit: notmandatory] 09:06 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #rust-bitcoin 09:16 <@andytoshi> stevenroose: i do not agree it is a "situational workaround" 09:17 <@andytoshi> yes, i was trolling, but because i think that whole issue should be thrown out 09:17 <@andytoshi> a public key, from bitcoin's perspective, has a compressedness flag. 09:17 <@andytoshi> so do private keys 09:18 <@andytoshi> if you lose that flag you cannot reconstruct it from the other data. and without that flag you cannot use the public key on the blockchain or derive addresses from it 09:18 < stevenroose> Yeah that's what I've also been repeating in the issue. Since we've been over it before, I would just close it as well. 09:47 < dpc> I'm not versed enough with script usage to comment on it. Though it looks like something that would at very least help user figure out which operations makes sense in a given context and what is what, helping to prevent mistakes. 09:48 < dr-orlovsky> I need this system for my own work, so I will work on its implementation anyway, and, once it's ready, I will do an issue and we'll decide whether it (or a part of it) may be useful for `rust-bitcoin` 10:13 < stevenroose> dr-orlovsky: out of curiosity, what kind of stuff are you doing with this. 10:13 < stevenroose> It seems a bit convoluted to me. 10:16 < dr-orlovsky> stevenroose: , README gives an introduction. Right now it is required from client-side validation - a paradigm by Peter Todd which we apply to manage rich off-chain state. One of the use cases - assets on L2/L3. We have to embed a commitments into public keys in different types of transaction outputs (we need to actually embed them into _any_ possible output) - and verify them in a deterministic manner. 12:27 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:39f5:978a:5b82:ba27] has joined #rust-bitcoin 12:28 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:39f5:978a:5b82:ba27] has quit [Client Quit] 13:26 < dpc> Why is https://docs.rs/bitcoin/0.23.0/bitcoin/blockdata/transaction/struct.Transaction.html#method.signature_hash taking `u32` instead of https://docs.rs/bitcoin/0.23.0/bitcoin/blockdata/transaction/enum.SigHashType.html ? Am I missing something? 13:36 <@andytoshi> because in principle you can put any 4-byte value there 13:36 <@andytoshi> and in practice you can put any one-byte value there 13:36 <@andytoshi> most of which will be treated like sighash all 14:15 < dpc> So `SigHashType` should just have `Other(u32)` ? 14:37 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Read error: Connection reset by peer] 14:48 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #rust-bitcoin 14:53 <@andytoshi> hmm 14:53 <@andytoshi> yeah, that's a good idea 14:53 <@andytoshi> though it then forces users to match on Other, which is annoying 14:53 <@andytoshi> because in (almost) every single case the behaviour should be the same as for All 14:57 < dr-orlovsky> This is what `#[non_exhaustive]` is designed for, however not sure whether it is supported by 1.22 15:03 <@andytoshi> ugh 15:03 <@andytoshi> if we use non_exhaustive what even is the point of having enums 15:36 < dr-orlovsky> `enum::Other()` signifies that there is a legit (currently existing) case/spec allowing value of type ``; while `#[non_exhaustive]` means that there is no valid known use cases for the values outside of the current enum, however devs must be ready that the spec may change in the future and cover `_ =>` case 15:37 <@andytoshi> oh i see 15:37 <@andytoshi> it sounds like this doesn't really help the ergonomics then 15:37 <@andytoshi> rather than forcing users to match on Other, we're forcing them to match _ 15:38 <@andytoshi> and (a) they could've matched on _ anyway, if they wanted; (b) it sucks to match on _ because then you're not future-proof 15:48 < dpc> You could have `is_effectively_sigall(&self)-> bool` or `to_effective(self) -> Self` to maybe(?) help ergonomics. I wonder - can some of these codes in the future become something else? The do, right? That would be soft-fork change. In that case maybe it is good that it forces users to think about it? 16:00 < dpc> The sighashtype appended to a signature I'm looking at right now is just one byte, so is everything here https://docs.rs/bitcoin/0.23.0/bitcoin/blockdata/transaction/enum.SigHashType.html `u32`? 16:01 < dpc> Even `SinglePlusAnyoneCanPay == 0x83` suggests one byte? 16:01 <@andytoshi> dpc: because 4 bytes are hashed 16:01 <@andytoshi> the other 3 are always zero, yes 16:01 <@andytoshi> but the existing code matches what core does 16:02 <@andytoshi> using a single byte would make use needlessly bcash-incompatible BTW 16:02 <@andytoshi> which would've lost me a lot of money 16:02 < dpc> But from the perspective of the user ... do I care how it is being hashed? Could I actually use a `sig_hash_type == 0xf000` ? 16:02 <@andytoshi> ? 16:02 <@andytoshi> yes, if you are a user computing a hash 16:02 <@andytoshi> you care about how it is being hashed 16:03 <@andytoshi> and in principle you could do this ... but there is no way to trigger such a code path in core 16:03 <@andytoshi> using data from the blockchain 16:03 < dpc> But I'm using https://docs.rs/bitcoin/0.23.0/bitcoin/blockdata/transaction/struct.Transaction.html#method.signature_hash for that. :D 16:03 <@andytoshi> yes :) 16:04 <@andytoshi> this is the function we're discussing 16:04 <@andytoshi> it takes a u32 because the equivalent in Core takes a u32 16:04 <@andytoshi> and this fact was used by bcash to enforce replay protection ... and i used the equivalent in rust-bitcoin to spent my bcashes 16:07 < dpc> Oh I get what you mean. So... in bcash you would hash something with higher 3 bytes not zero? 16:07 < dpc> But in the tx only the last byte will apear? 16:07 <@andytoshi> yeah 16:07 < dpc> 3 higher bytes will just alter the calucalted `sig_hash`? 16:07 <@andytoshi> this is a weak argument for keeping it. rust-bitcoin really doesn't care about bcash 16:07 <@andytoshi> yep 16:08 <@andytoshi> but we do care about core compatibility 16:08 <@andytoshi> anyway ... i wouldn't argue too hard against making it a u8 16:08 <@andytoshi> but if we made it a SigHashType, then we'd have to modify SigHashType in some unergonomic way 16:08 < dpc> OK. So I get it, but it's kind of confusing to the user. And as a user of `rust-bitcoin` I can be a bit clueless and still get the job done. :D 16:09 < dpc> I guess I'll just fill a quick PR to add that to the docstring. 16:09 <@andytoshi> i mean, this reflects a dark corner of bitcoin which is legitimately confusing 16:09 <@andytoshi> but yeah, more docs are definitely welcome 16:50 < dpc> I submitted the PRs, but I am still confused about one thing. The "Type" word in `SigHashType`. So the value that is being hashed ... is it a type of the hash to sign, or is Type just the type of "SigHash" value? 16:50 < dpc> It's so hard to explain clearly, but there's something fishy about `SigHashType::from_u32(0xff).as_u32() != 0xff` unless I'm confused about the meaning of the name. 17:19 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:1442:a78a:fdc2:1086] has joined #rust-bitcoin 18:19 < stevenroose> dpc: where did you get that line? The sighashtype refers to the way the hash to sign is derived. Basically which elements of the tx to include in that hash. So you can see the word "type" as "which of the different ways to construct the signature hash". 18:52 < gwillen> dpc: fwiw, "sighash flags" is the term used most places for what I believe is the same thing 18:52 < gwillen> I assume it got renamed here because calling it "flags" is kind of misleading 20:07 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:1442:a78a:fdc2:1086] has quit [Remote host closed the connection] 20:08 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:1442:a78a:fdc2:1086] has joined #rust-bitcoin 20:18 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:1442:a78a:fdc2:1086] has quit [] 20:37 -!- notmandatory [~textual@cpe-76-169-37-102.socal.res.rr.com] has joined #rust-bitcoin 20:42 -!- notmandatory [~textual@cpe-76-169-37-102.socal.res.rr.com] has quit [Ping timeout: 272 seconds] 20:58 -!- notmandatory [~textual@185.236.200.174] has joined #rust-bitcoin 21:03 -!- notmandatory [~textual@185.236.200.174] has quit [Ping timeout: 265 seconds] 21:03 -!- notmandatory [~textual@84.17.37.67] has joined #rust-bitcoin 21:10 -!- notmandatory [~textual@84.17.37.67] has quit [Quit: notmandatory] --- Log closed Sat Jan 25 00:00:20 2020