--- Log opened Wed Oct 07 00:00:39 2020
01:35 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #rust-bitcoin
01:39 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 272 seconds]
01:55 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 265 seconds]
01:56 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 240 seconds]
02:09 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #rust-bitcoin
02:30 -!- jonatack [~jon@213.152.162.94] has joined #rust-bitcoin
02:42 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 240 seconds]
03:03 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Read error: Connection reset by peer]
03:06 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #rust-bitcoin
03:09 -!- belcher_ is now known as belcher
03:20 -!- Piper8Stiedemann [~Piper8Sti@static.57.1.216.95.clients.your-server.de] has joined #rust-bitcoin
03:22 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #rust-bitcoin
04:01 -!- tibo [~tibo@2400:4050:2a83:7000:8443:2c82:af77:7c71] has quit []
04:14 -!- Piper8Stiedemann [~Piper8Sti@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 272 seconds]
04:19 -!- shesek [~shesek@164.90.217.137] has joined #rust-bitcoin
04:19 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]
04:19 -!- shesek [~shesek@unaffiliated/shesek] has joined #rust-bitcoin
04:22 -!- tibo [~tibo@2400:4050:2a83:7000:53a:751:40b5:de50] has joined #rust-bitcoin
04:44 -!- jonatack [~jon@213.152.162.94] has quit [Ping timeout: 246 seconds]
05:28 -!- tibo [~tibo@2400:4050:2a83:7000:53a:751:40b5:de50] has quit [Remote host closed the connection]
05:33 -!- dpc1 [dpcmatrixo@gateway/shell/matrix.org/x-irvrkmaaegdlbbtf] has quit [Quit: killed]
05:34 -!- icota[m]1 [icotamatri@gateway/shell/matrix.org/x-sxcivdfavteepvuu] has quit [Quit: killed]
05:41 -!- dpc [dpcmatrixo@gateway/shell/matrix.org/x-kptjmuqsqbpgndky] has joined #rust-bitcoin
05:58 -!- icota[m] [icotamatri@gateway/shell/matrix.org/x-zjoqpgpgseeabplt] has joined #rust-bitcoin
06:04 -!- Netsplit *.net <-> *.split quits: kallewoof, gribble, Blackwolfsa4, neonknight64
06:09 -!- kallewoof [~quassel@240d:1a:759:6000:a7b1:451a:8874:e1ac] has joined #rust-bitcoin
06:09 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #rust-bitcoin
06:13 -!- varioust [~varioust@rrcs-76-79-47-154.west.biz.rr.com] has joined #rust-bitcoin
06:38 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #rust-bitcoin
07:04 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
07:14 -!- icota[m] [icotamatri@gateway/shell/matrix.org/x-zjoqpgpgseeabplt] has quit [Quit: Idle for 30+ days]
07:44 < andytoshi> BlueMatt: what do you think about https://github.com/rust-bitcoin/rust-bitcoin/pull/486 ?
07:44 < andytoshi> stevenroose: ^ can i get a concept ack? or are you still opposed to it?
07:56 < andytoshi> thanks!
07:57 < andytoshi> gonna try to do a minor rust-bitcoin release today .. if anybody has PRs that thy really want in please ping me (tho i'm gonna go throug hthe whole list)
07:58 < stevenroose> let me check
07:59 < andytoshi> heh so right off the bat https://github.com/rust-bitcoin/rust-bitcoin/pull/249 is our oldest open PR and it looks ready
07:59 < andytoshi> let me review thuogh
07:59 < andytoshi> oh, bitcoin_constants is older but that's not gonna get into a minor release
08:01 < stevenroose> https://github.com/rust-bitcoin/rust-bitcoin/pull/489
08:01 < stevenroose> andytoshi: should I squash?
08:26 < stevenroose> andytoshi: also redid this one: https://github.com/rust-bitcoin/rust-bitcoin/pull/444
08:32 < stevenroose> andytoshi: also squashed 249
08:36 < stevenroose> https://github.com/rust-bitcoin/rust-bitcoin/pull/414 perhaps? :)
08:38 < andytoshi> heh on a call for the next 20 mins or so, but thanks!
08:51 < stevenroose> also cleaned up and rebased https://github.com/rust-bitcoin/rust-bitcoin/pull/413
08:51 < stevenroose> :D
08:51 < stevenroose> sorry, I noticed i had quite some stale PRs open
08:55 < andytoshi> lol all good. i spent like 8 months somehow not maintaining rust-bitcoin at all (i swear, this year has evaporated..)
08:56 < stevenroose> yeah I have the same feeling. a lot I think is Covid, somehow, even though it should have given most of us more time instead of less. somehow I think I spent most of that time working :/
08:58 < BlueMatt> andytoshi: yea, no strong opinion there, seems strange, but kinda whatever.
09:07 < andytoshi> stevenroose: yeah, me too .. and yet. this blog post talks about this a little bit https://www.raptitude.com/2020/05/focus-on-the-inputs/
09:07 < andytoshi> ok call over. looking at 249
09:07 < andytoshi> lol you dismissed sgeisler review...so we need a second reviewer now
09:08 < sgeisler> andytoshi: where? I can reACK
09:09 < andytoshi> sgeisler: https://github.com/rust-bitcoin/rust-bitcoin/pull/249
09:09 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
09:10 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin
09:10 < andytoshi> stevenroose: ok so your first commit does not compile :)
09:10 < andytoshi> error: unused import: `hashes::hex::FromHex` --> src/util/bip152.rs:378:9
09:15 < sgeisler> Re-acked, it didn't touch any existing critical parts and I kinda trust stevenroose not to introduce actual bugs in the rebase, so it's not a super thorough review. If I shall do a full review that's ok too, but that would be later today/tomorrow. So I figured if andytoshi is looking at it anyway it's better to get out of the way.
09:16 < andytoshi> yeah nah, i'll do a full review
09:16 < andytoshi> but that's blocked on the commit history compiling :)
09:16 < sgeisler> (I originally did a rather thorough review with the spec open, but that was some time ago)
09:18 < andytoshi> whew there is a lot inthe PR list that i'd like to get in on the next major version..
09:22 < andytoshi> stevenroose: can you re-review https://github.com/rust-bitcoin/rust-bitcoin/pull/388 ? it's short and well-tested
09:28 < elichai2> andytoshi: is it really important for you that all the commits pass tests?
09:38 < andytoshi> elichai2: yes
09:38 < andytoshi> otherwise it breaks bisection
09:38 < andytoshi> and it also makes review harder
09:39 < elichai2> ok, I just sometimes separate logic changes and test changes to 2 separate commits
09:39 < andytoshi> yeah, that's reasonable, and unfortunate that git gives you no way to mark a commit as "failing, skip during bisection"
09:39 < andytoshi> i'd be ok if you commented out the failing test, or added a #[should_panic] to it for one commit
09:40 < stevenroose> acked 388
09:40 < stevenroose> I don't see which commit has that warning, andytoshi I compiled all 3 of them in 249
09:41 < andytoshi> maybe you need the serde feature on
09:41 < andytoshi> hmm no .. i get this on 9cacbe08d293aa78547c6474ccd55e0c68249bd6 with just `cargo test`
09:42 < andytoshi> rust 1.46
09:48 < stevenroose> andytoshi: looks like you merged the iter -> instrucitons change which is breaking
09:49 < stevenroose> if you'd have waited with that, we could have done a minor version bump :| alternatively we can quickly create a release branch at the end of merging all this to bring back the iter() function as an alias for the new functions
09:50 < jrawsthorne> stevenroose: did you see my suggestion for 249
09:50 < stevenroose> k, fixed and rebased https://github.com/rust-bitcoin/rust-bitcoin/pull/444 again (it got broken by merging the iter -> instructions change)
09:51 < andytoshi> stevenroose: hmmm dammit
09:51 < andytoshi> yeah can we just make a PR which aliases iter() to instructions and marks it deprecated?
09:52 < jrawsthorne> Anyone willing to review https://github.com/rust-bitcoin/rust-bitcoin/pull/446 and https://github.com/rust-bitcoin/rust-bitcoin/pull/454. They're pretty small
09:53 < andytoshi> stevenroose: i'm confused, what PR are you talking abotu? seems like that happened before 0.25
09:53 < andytoshi> before 0.24.0
09:54 -!- rloomba [~rloomba@2601:646:100:3410:9446:c612:21bf:9620] has joined #rust-bitcoin
09:55 < andytoshi> jrawsthorne: unfortunately 446 is a breaking change and needs a major release
09:55 < andytoshi> because it modifies public structs
09:55 < stevenroose> jrawsthorne: ah yeah I just noticed and added it. andytoshi  also fixed the FromHex thing, sorry. here: https://github.com/rust-bitcoin/rust-bitcoin/pull/249
09:55 < stevenroose> andytoshi: will do iter
09:56 < andytoshi> jrawsthorne: err 454. looking at 446 now
09:56 < andytoshi> stevenroose: i don't think we need to do anything about iter
09:57 < andytoshi> 446 is also breaking, changes a public enum
09:59 < elichai2> i'm kinda surprised we almost never had complains about the frequency of breaking changes in rust-bitcoin
10:00 < jrawsthorne> andytoshi: ah yeah, no rush really
10:00 < elichai2> which means that either our users are really informed and know what they're doing, or we always break niche things?
10:00 < elichai2> it even seems that most of our users are using the 2 latest majors
10:01 < andytoshi> elichai2: (a) we're super anal about bumping the version number when we do breaking changes; (b) our users are missing features for months so as soon as a new major version comes out they jump on it :P
10:01 < stevenroose> andytoshi: https://github.com/rust-bitcoin/rust-bitcoin/pull/490 : add back Script::iter as deprecated
10:02 < elichai2> andytoshi: I meant even across version bumps, in a lot of big libraries people complain because of the upgrade churn
10:02 < stevenroose> oh did that happen before 0.25? hmm then I just didn't rebase that other PR yet, let me check and close 490 then
10:03 < stevenroose> you're right, ignore 490 :)
10:07 < stevenroose> elichai2: added your suggestion on https://github.com/rust-bitcoin/rust-bitcoin/pull/489
10:48 < andytoshi> elichai2: yeah, that's true, honestly idk why we don't get more flack. though in fairness we are still 0.x
10:50 < BlueMatt> if rust-lightning is any indication, we use, like, a tiny, tiny, tiny fraction of rust-bitcoin - basically just transaction and script-building (but not even, really, introspection).
10:50 < BlueMatt> I imagine many users are similar
10:52 < andytoshi> yeah, ditto for liquid
11:03 < stevenroose> sgeisler: any chance you could re-review https://github.com/rust-bitcoin/rust-bitcoin/pull/444?
11:06 < sgeisler> Done, nice work! Looks much cleaner than on the first pass.
11:15 < stevenroose> jrawsthorne: could you squash your both PRs?
11:15 < stevenroose> sgeisler: nice thanks :)
11:26 < andytoshi> running 444 through tests, will merge when it passes
11:59 -!- varioust [~varioust@rrcs-76-79-47-154.west.biz.rr.com] has quit [Quit: varioust]
12:10 < jrawsthorne> stevenroose: squashed both of those
12:13 < andytoshi> doc fix https://github.com/rust-bitcoin/rust-bitcoin/pull/488 can i have a second ack?
12:14 < stevenroose> https://github.com/rust-bitcoin/rust-bitcoin/pull/249 is passing CI
12:15 < stevenroose> merged 488
12:15 < stevenroose> I like this review sprint. sgeisler just suggested in private they we could try schedule these monthly or so
12:16 < stevenroose> it's productive to review PRs while the authors is present to iterate on it
13:27 < andytoshi> hmm yeah, scheduling these seems like a good idea
13:27 < andytoshi> (sorry, i stepped out for a couple hours, back now)
13:29 < andytoshi> reviewing 249
13:30 < andytoshi> so .. strictly speaking this is a breaking change because we're adding stuff to the network message enum
13:39 < andytoshi> i think maybe we could do a major release after the minor one
13:53 < stevenroose> ah, well you can also add a tag to the PR saying "ready for merge but breaking" and then we wait for a breaking release to do it
13:53 < stevenroose> I don't think anyone is anxiously waiting for this anyway
13:57 < stevenroose> btw, I just redid my taproot tagged hashes PR using newtypes instead of type aliases and discovered that the hash_newtype engine impl is a bit broken: https://github.com/rust-bitcoin/bitcoin_hashes/pull/93
13:57 < andytoshi> kk
13:57 < stevenroose> but only for special engine-usage, so only for the tagged hashes :p
13:59 < andytoshi> heh, is this actually a breaking change?
14:00 < andytoshi> i guess it prevents users from impl'ing `Hash::engine()` themselrves
14:08 < stevenroose> they couldn't already anyway
14:08 < stevenroose> it's breaking for users that use tagged hashes because the tagged hashes' default impl for engine is the default sha256 engine
14:09 < andytoshi> heh, well, that behavior was objectively wrong
14:09 < stevenroose> andytoshi: my taproot branch broke when I changed it to using newtypes and worked again when I added this, because then it calls the engine() method on sha256t::Hash which calls the Tag::engine method
14:09 < andytoshi> yeah, i think this is just a bugfix
14:10 < stevenroose> yeah I mean no one is using tagged hashes for now AFAIK, but it's breaking in principle for them
14:10 < andytoshi> because the behavior changed?
14:10 < andytoshi> it changed from being wrong to not being wrong :)
14:10 < stevenroose> dr-orlovsky has been talking about moving the tagged_hash_newtype macro that I use in the taproot PR into bitcoin_hashes, which might make sense
14:11 < stevenroose> yeah it changed from being wrong to not being wrong, indeed :)
14:11 < andytoshi> yeah, i think tagged_hash_newtype is a good complement to the existing hash_newtype
14:11 < andytoshi> and does belong in bitcoin_hashes
14:12 < dr-orlovsky> stevenroose:
14:12 < dr-orlovsky> > yeah I mean no one is using tagged hashes for now AFAIK, but it's breaking in principle for them
14:12 < dr-orlovsky> I do use them a lot :)
14:12 < andytoshi> i'm gonna go ahead and merge this in and do a minor release :P
14:12 < andytoshi> stevenroose: can you PR to add the tagged hashes macro?
14:12 < andytoshi> or dr-orlovsky ?
14:12 < stevenroose> dr-orlovsky: do you use them together with newtypes?
14:12 < dr-orlovsky> yes
14:13 < stevenroose> hmm
14:13 < stevenroose> because actually I would consider the current behavior a bug
14:13 < dr-orlovsky> reading what the discussion was about
14:13 < stevenroose> so it might justify a minor release as it fixes a bug
14:13 < andytoshi> dr-orlovsky: the issue is that the current tagged hash engine fails to tag the hashes it produces :P
14:14 < stevenroose> andytoshi: then wait for the macro for the minor release, I'll go ahead and add it in a slightly more generic way
14:14 < andytoshi> stevenroose: +1
14:14 < dr-orlovsky> feel free to change whatever is needed, I can fix my version since it's not used in production yet
14:16 < stevenroose> hmm, I'm feeling a bit like the macro is so trivial, it's a bit lame to upstream it. it's more there to reduce having to type that thing 4 times
14:16 < stevenroose> well let me do it and then we judge
14:20 < andytoshi> stevenroose: can you quickly utack https://github.com/rust-bitcoin/rust-bitcoin/pull/459/files ? it adds 6 LOC
14:21 < stevenroose> andytoshi: ack'd
14:22 < stevenroose> andytoshi, dr-orlovsky: https://github.com/rust-bitcoin/bitcoin_hashes/pull/94
14:24 < andytoshi> thanks
14:26 < dr-orlovsky> commented there
14:26 < dr-orlovsky> BTW I am looking forward for the time where we can have a derive macros for hash newtypes... Had some effort on this with elichai2:, but were stuck with MSRV not supporting syn v1
14:27 < andytoshi> oh good catch that Debug is missing
14:27 < andytoshi> dr-orlovsky: fwiw we can use an old version of syn .. cf whatever the version of serde that we pin uses
14:27 < andytoshi> but yeah, taht's probably ugly and annoying to use
14:28 < andytoshi> plus it'd force a dep on an old version of syn on all of our users, which sucks. we just updated liquid to latest serde and we have vendored syn v1 and i'd be annoyed if we also had to vendor v0.6
14:30 < dr-orlovsky> "Syn supports rustc 1.31 and up." - seems like we are really close to the target!
14:31 < stevenroose> k added Debug there and it works with the taproot branch I have locally
14:32 < andytoshi> dr-orlovsky: lol, 1.29 to 1.31 is a huuuge difference because that's the rust 2018 change
14:32 < stevenroose> ah perhaps I should change the order of the reverse and docs arguments
14:32 < stevenroose> so that they are the same as for hash newtype?
14:32 < stevenroose> should I also make the reverse one optional?
14:33 < dr-orlovsky> if we ever get there, we may use a lot of good derivation macros from https://crates.io/crates/amplify_derive which I did with syn v1 basing on the original elichai2: work in derive_wrapper (unfortunately it was based on old syn, so I had to re-do some stuff)
14:33 < andytoshi> yes, i think they should match hash_newtype, and yes i think reverse should be optional
14:33 < dr-orlovsky> agree
14:33 < andytoshi> dr-orlovsky: lol, well, we will one day .. but yeah, many many things will be better in 1.31
14:34 < dr-orlovsky> Didn't know about which version introduced 2018... Hopefully we will be there one day :)
14:34 < stevenroose> hmm andytoshi not sure about optional, the dfault would be the "inner" one, but for sha256t, the inner type is not really a type, it's a generic type
14:35 < stevenroose> I changed the order, I thikn for now we should have the reverse be explicit, idk what taproot is going to do, but I don't feel comfortable having a strong default value atm
14:35 < stevenroose> (the default value that I _had_ to set for sha256t::Hash<T> is true, but that's just random
14:35 < andytoshi> ok, i'm alright with that
14:37 < dr-orlovsky> me too. Btw, why not to define Taproot-related hastypes right in bitcoin_hashes crate? Or better to wait till their adoption in Bitcoin Core?
14:39 < andytoshi> better to wait
14:39 < andytoshi> but yeah, i think eventually it'll make sense to pull the taproot ones into bitcoin_hashes
14:40 < stevenroose> ah yeah good point
14:40 < stevenroose> ok I think I'm final on the bitcoin_hashes pr
14:41 < andytoshi> heh kk rereviweng
14:42 < andytoshi> i'm really happy with this, we'll use this in rust-simplicity
14:42 < andytoshi> i guess if i wanted to be a good reviewer i'd actually try to use it in rust-simplicity..
14:43 < stevenroose> no hurry on this one though
14:43 < stevenroose> taproot in rust-bitcoin probably won't get merged before taproot is final, right?
14:43 < stevenroose> and i'm off to bed, so take your time
14:43 < andytoshi> well, if we merge it now we can do a new minor release right now
14:43 < andytoshi> stevenroose: correct
14:44 < stevenroose> no hurry for the release either..
14:44 < stevenroose> anyway, g'night and see yah tomorrow
14:44 < andytoshi> night!
15:03 < andytoshi> minor rust-bitcoin version (everything i skipped either seemed to need a lot of work, or was a breaking change ... but feel free to ask me to include more stuff)
15:04 < andytoshi> https://github.com/rust-bitcoin/rust-bitcoin/pull/491
15:04 -!- jrawsthorne [~jrawsthor@static.235.41.217.95.clients.your-server.de] has quit [Quit: ZNC 1.8.1 - https://znc.in]
15:04 -!- jrawsthorne [~jrawsthor@static.235.41.217.95.clients.your-server.de] has joined #rust-bitcoin
15:04 < andytoshi> BlueMatt: stevenroose: dongcarl: elichai2: ^
15:04 < andytoshi> whoever else can ack
15:06 -!- ariard [~ariard@167.99.46.220] has quit [Ping timeout: 240 seconds]
15:06 < dr-orlovsky> andytoshi: what about hash preimages for PSBT? I do not see why they are breakin and the PR was reviewed some time ago
15:07 -!- ariard [~ariard@167.99.46.220] has joined #rust-bitcoin
15:07 < dr-orlovsky> I mean https://github.com/rust-bitcoin/rust-bitcoin/pull/478
15:11 < andytoshi> dr-orlovsky: because it only had one ack on it
15:11 < andytoshi> zero*
15:11 < andytoshi> so i wasn't able to merge it by myself :P
15:11 < andytoshi> lemme review it and we'll see if we can get another ack tomorrow
15:11 < andytoshi> because actually i really want this PR, we need it for rust-miniscript (probably this is your motivation too :))
15:12 < dr-orlovsky> exactly :)
15:15 < andytoshi> dr-orlovsky: so, by adding stuff to the psbt Error enum, that makes this a breaking change
15:16 < andytoshi> it's a bit silly ... i can't imagine anybody was matching on the entire error enum without any wildcards .. but those are the rules
15:18 < andytoshi> oh #480 should get in
15:19 < dr-orlovsky> andytoshi: yeah, we don't have #[non_exhaustive] yet :(
15:20 < andytoshi> how does #[non_exhaustive] even work?
15:20 < andytoshi> forces users to include a wildcard?
15:20 < dr-orlovsky> it says that users of the enum must provide wildcard match
15:20 < andytoshi> gotcha
15:20 < dr-orlovsky> so when you add options this is not a breaking change
15:21 < dr-orlovsky> andytoshi: takin an opportunity to ask: what about adding tweaking info to PSBT as a standard output KEY in BIP?
15:21 < dr-orlovsky> elements/liquid needs that, and me too :)
15:22 < andytoshi> dr-orlovsky: so, i proposed this on the mailing list, and it got no responses (i think achow weakly acked it)
15:22 < andytoshi> but the reason i didn't make an actual proposal/PR
15:22 < andytoshi> is that the elements derivation algorithm is pretty shitty
15:22 < andytoshi> iirc it uses an hmac for no reason and doesn't use tagged hashes
15:22 < andytoshi> so i was torn between wanting to propose a "good" way of doing key derivation in PSBT and descriptors
15:23 < andytoshi> and wanting to propose something that was compatible with liquid
15:23 < dr-orlovsky> PSBT key may not depend on specific commitment algorithm; it can be any 32-bytes which can be converted into EC field member (i.e. <n)
15:23 < dr-orlovsky> this will be both liquid and other commitment schemes compatible
15:24 < andytoshi> :eek:
15:24 < andytoshi> that would also enable pretty broken crypto
15:24 < dr-orlovsky> regarding the commitment scheme we have this one: https://github.com/LNP-BP/LNPBPs/blob/master/lnpbp-0001.md
15:24 < dr-orlovsky> still uses HMAC, but with tagged hashes though and can operate on P2(W)SH outputs in Lightning
15:25 < andytoshi> nice
15:25 < andytoshi> and i take it you can't feasibly change that to match some idealistic standard?
15:26 < dr-orlovsky> * sorry refresh the link, just merged PR into it with many improvements, test vectors, reference impl etc
15:26 < andytoshi> for liquid our plan initially was to use proprietary PSBT fields (which, come to think of it, are also not in the BIP are they..)
15:26 < andytoshi> but then actually we found we didn't want to use psbt at all
15:26 < andytoshi> for our functionary protocol
15:27 < andytoshi> required way too many cross-checks to pass complete transactions around (is the version right? are the sequence nos right? are the locktimes right? etc etc etc), so we instead pass around a "transaction proposal"
15:27 < andytoshi> which is a list of inputs to use, list of pegouts to turn into txouts, and a list of change amounts
15:28 < andytoshi> and we have a canonical way of constructing a transaction from that
15:28 < dr-orlovsky> basically you do not need PSBT tweak key anymore and PSBT at all?
15:28 < andytoshi> for the functionary protocol, that's correct
15:28 < andytoshi> but i think we may still want it if we want to suppport doing pegins with PSBT wallets
15:29 < andytoshi> but i'm not aware of anyone working on that
15:29 < dr-orlovsky> I am willing to propose BIP PR with tweaks; so what would be the most generic (and at the same time cryptographically-secure) format for tweak data?
15:31 < dr-orlovsky> I assume it's anyway 32-bits, and they must be convertible into SecretKey (otherwise tweak can't be applied), and derived PublicKey must not be a negation of the tweaked key. So this all can be a part of checks included in the spec
15:31 < dr-orlovsky> *32-bytes, 256 bits
15:31 < andytoshi> i really don't like that
15:31 < andytoshi> it lets people do horrendously insecure things
15:32 < andytoshi> btw new bitcoin_hashes minor version https://github.com/rust-bitcoin/bitcoin_hashes/pull/96
15:33 < dr-orlovsky> andytoshi: I really don't get how tweak can be securely serialized than...
15:34 < andytoshi> by providing data that gets put into a hash along with the original key
15:34 < andytoshi> this ensures that no data can change the set of people who know the secret key
15:35 < dr-orlovsky> ok, that is why the commitment procedure has to be standartized...
15:36 < andytoshi> so, taproot kinda does this
15:36 < andytoshi> i'd like to see a standard which was just the taproot derivation with a differently tagged hash
15:36 < andytoshi> or maybe let the user specify the tag
15:37 < andytoshi> which is a tiny bit insecure because i think if you let them specify the taproot tag, there are plausible attacks on plausible protocols where you insert a "surprise" taproot commitment
15:39 < dr-orlovsky> well, there could be two tags, like in that LNPBP-1, which will allow to customize, but not to collide with taproot tag (so there will be required part of the tag which will prevent ability to create tag lokking exactly like taproot one)
15:42 < andytoshi> yeah i could get behind that
16:07 -!- shesek [~shesek@164.90.217.137] has joined #rust-bitcoin
16:07 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]
16:07 -!- shesek [~shesek@unaffiliated/shesek] has joined #rust-bitcoin
16:27 -!- tibo [~tibo@2400:4050:2a83:7000:9c54:8320:efb2:4ec] has joined #rust-bitcoin
17:00 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
17:05 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin
18:38 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has quit [Ping timeout: 265 seconds]
18:47 -!- rloomba [~rloomba@2601:646:100:3410:9446:c612:21bf:9620] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
19:52 -!- tibo_ [~tibo@2400:4050:2a83:7000:8112:882c:f66a:d4f1] has joined #rust-bitcoin
19:55 -!- tibo [~tibo@2400:4050:2a83:7000:9c54:8320:efb2:4ec] has quit [Ping timeout: 240 seconds]
21:20 -!- rjected_ [~dan@pool-71-184-77-198.bstnma.fios.verizon.net] has quit [Ping timeout: 258 seconds]
23:35 -!- dpc [dpcmatrixo@gateway/shell/matrix.org/x-kptjmuqsqbpgndky] has quit [Quit: killed]
23:42 -!- icota[m] [icotamatri@gateway/shell/matrix.org/x-ihqyrxcofnkxpzjr] has joined #rust-bitcoin
23:59 -!- dpc [dpcmatrixo@gateway/shell/matrix.org/x-vplinyxrydvtbhrg] has joined #rust-bitcoin
--- Log closed Thu Oct 08 00:00:15 2020