--- Log opened Mon Oct 05 00:00:38 2020
00:33 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 260 seconds]
00:54 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
00:55 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #rust-bitcoin
01:35 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #rust-bitcoin
01:38 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds]
01:42 -!- jonatack [~jon@213.152.161.170] has joined #rust-bitcoin
01:54 -!- belcher_ is now known as belcher
02:56 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-irdcinsacsmbwsbs] has joined #rust-bitcoin
03:01 -!- ulrichard [~richi@212.71.103.20] has joined #rust-bitcoin
03:05 < ulrichard> Hi, I want to replicate an electrum p2wsh-p2sh multisig wallet with rust-wallet. There is nothing about multisig wallets in the examples I found. Do I have to construct the script mself with a scripter like in "Advanced Accounts Use" with they pubkeys that I derive from the xpubs per signer?
03:23 -!- jonatack [~jon@213.152.161.170] has quit [Ping timeout: 265 seconds]
04:16 -!- jonatack [~jon@37.171.243.133] has joined #rust-bitcoin
04:18 -!- Bernita59Hane [~Bernita59@static.57.1.216.95.clients.your-server.de] has joined #rust-bitcoin
04:22 -!- jonatack [~jon@37.171.243.133] has quit [Read error: Connection reset by peer]
05:54 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #rust-bitcoin
05:59 < ariard> ulrichard: have a look on bdk https://github.com/bitcoindevkit/bdk, they might have what you're looking for, it's a wallet toolkit
05:59 < ariard> IIRC there is no ready-to-use multisig scripts in rust-bitcoin
06:03 -!- Bernita59Hane [~Bernita59@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 240 seconds]
06:12 < ulrichard> ariard: Thanks, I will look into that.
06:15 -!- tibo [~tibo@2400:4050:2a83:7000:2c4c:7fdb:192e:610] has quit [Remote host closed the connection]
06:28 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:cd28:750c:410c:649a] has joined #rust-bitcoin
06:44 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
07:28 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:cd28:750c:410c:649a] has quit []
08:11 < ariard> BlueMatt: yeah I've at least another bug-fix in mind, lmk when you looked on #716/#722, pending on you :)
08:18 < BlueMatt> oh are they? oops, sorry.
08:23 < BlueMatt> ariard: ah, well you point out a good point on IRC, too...we should be rounding weight up in the minimum-fee test, which that pr didnt do :)
08:31 -!- ulrichard [~richi@212.71.103.20] has quit [Remote host closed the connection]
08:31 < BlueMatt> ariard: ok, take a look at https://github.com/rust-bitcoin/rust-lightning/pull/716 again
08:35 < ariard> looking on
08:36 < BlueMatt> ariard: to be clear, you want me to remove the cfg here? https://github.com/rust-bitcoin/rust-lightning/pull/722#discussion_r499097901
08:40 < ariard> BlueMatt: just a nit https://github.com/rust-bitcoin/rust-lightning/pull/716#discussion_r499692797
08:40 -!- wraithm_ [~wraithm@unaffiliated/wraithm] has quit [Quit: ZNC 1.6.3+deb1+xenial0 - http://znc.in]
08:40 < BlueMatt> lol duh
08:41 < ariard> BlueMatt: yes I think we can remove the cfg, unless as a general stand we don't do assert in production
08:41 < ariard> but I think we have already asserts in prod?
08:42 < BlueMatt> yea, no, def. i mean my theory has always been the kinda core thinking of "assert if failure would imply that we're going to do something wrong, eg lose money"
08:43 < ariard> so that's the case of losing money as it would be a hint of not tracking remote commitment and we MUST to react properly?
08:44 < BlueMatt> presumably, yes. its def not a hard rule
08:44 < BlueMatt> more of a guideline
08:45 -!- wraithm [~wraithm@unaffiliated/wraithm] has joined #rust-bitcoin
08:45 < ariard> sure, your call here, at least add a comment pointing on consistency requirement between the 2 structs if you don't keep the assert
08:50 < BlueMatt> right. alright, well i dont feel strongly...I'll just drop the cfg and move on
08:56 < BlueMatt> ariard: ok, done.
08:58 < ariard> looking in a minute
09:14 < ariard> BlueMatt: both SGTM
09:18 < BlueMatt> awesome. will merge when tests pass...what else do you want for next-release? also 681?
09:23 -!- vindard [~vindard@190.83.165.233] has quit [Ping timeout: 260 seconds]
09:25 < ariard> I already did a new round on #681
09:25 < ariard> BlueMatt: okay #611 is the bug-fix I had in mind
09:25 < BlueMatt> oh, sorry, i meant 653
09:26 < ariard> yep rebasing it
09:26 -!- vindard [~vindard@190.83.165.233] has joined #rust-bitcoin
09:26 < BlueMatt> cool
09:29 < ariard> BlueMatt: okay looking on #611, we may have another weird onchain-to-offchain corner casd not handled well
09:30 < BlueMatt> oh? I thought we handled onchain-to-offchain right. just the off-to-off is the issue.
09:30 < ariard> BlueMatt: in case of remote commitment hitting the chain, receiving at the same time a offchain revocation from remote
09:30 < ariard> do we have a guarantee we will punish the now-revoked commitment ?
09:31 < ariard> I think nothing prevent a revocation to happen after a commitment confirmation if we haven't yet processed the block?
09:33 < ariard> so even if it sounds a race case, when we ChannelMonitor::provide_secret we should also verify we haven't seen a remote commitment and if so generate a justice?
09:34 < BlueMatt> I dont believe we're going to punish them for attempting to revoke post-relay, no, but I'm not sure how we really would. We def should reject the update in CHannelMonitor, though
09:34 < BlueMatt> if we dont thats indeed a bug
09:36 < BlueMatt> err, is it?
09:37 < ariard> well in fact you can tell we're safe because we would reject ChannelMonitorUpdateStep::LatestCommitmentTXInfo
09:37 < BlueMatt> I mean they can revoke it doesnt really matter, as long as we dont accept new htlcs
09:37 < BlueMatt> right, ok.
09:37 < ariard> but in fact the remote confirmation may happen in the middle of the commitment dance
09:37 < ariard> so after we accept our new state but before we recieve remote revocation
09:39 < ariard> your remote peer send update+CS, you accept it and send to your monitor LatestCommitmentTXInfo, you send to your monitor LatestCounterpartyCommitmentTXInfo and send RAA+CS to your remote peer
09:40 < ariard> the remote N-1 is confirmed onchain then you receive remote RAA
09:42 < BlueMatt> right, so we may not punish in that case (which I think is ok?) but we should still enforce all the correct states, no?
09:42 < BlueMatt> like, is there some case where we accept the wrong tx or so?
09:44 < BlueMatt> errr, like, where we'd now not claim an htlc by preimage or somethign?
09:44 < ariard> sure it wouldn't be an error on HTLC claiming
09:44 < BlueMatt> like, in general we should handle it correctly because if we didnt we'd *also* not handle it correctly if we receive N-1 without ever receiving the RAA
09:44 < ariard> because the new updated HTLCs can't be claim onchain (unless reorgs)
09:45 < ariard> but it sounds to me the acceptance of remote RAA is dependent on calling revoke_and_ack before or after block_connected
09:45 < BlueMatt> right, i think I dont disagree that we *should* reject the RAA monitor-update
09:45 < BlueMatt> but I dont think it will result in different behavior?
09:45 < ariard> and I'm quite sure we don't
09:46 < BlueMatt> ugh...wtf rust? profile.test isn't used in testing, you have to set it in profile.dev :(
09:46 < ariard> lol like the workspace which prevent passing down the feature flags
09:46 < ariard> let me open an issue and I'll write a test to be sure we handle it well
09:46 < BlueMatt> i dont even think its a workspace issue :(
09:47 < BlueMatt> ok, i mean feel free to just open a pr with a new test. I dont think its wrong, so an isue may not be the right response :)
09:47 < ariard> let me fix 653 first (and I open an issue to be sure I won't forget in-between :p )
09:47 < ariard> the issue space is almost free
09:50 < BlueMatt> heh, fair enough
09:52 < BlueMatt> ariard: oh, oops, can you glance at https://github.com/rust-bitcoin/rust-lightning/pull/734 ?
09:52 < BlueMatt> its quite annoying, right now if you dont rebase your pr on git HEAD CI fails.
09:53 < ariard> ah good this explains why my anchor PRs are failing
09:54 < ariard> BlueMatt: how I'm supposed to test 734 ?
09:54 < BlueMatt> yea, i thought I'd merged it and was wondering why my pr was failing lol
09:54 < BlueMatt> ariard: "This PR is deliberately based on a stale version of git upstream to test it."
09:54 < BlueMatt> check that it is based on out-of-date main and note that CI passed :)
09:55 < BlueMatt> or cherry-pick the commit onto another one of your prs, push, and watch ci pass
09:55 < ariard> doing second
09:56 < ariard> for 653, we can't add test coverage for now as the bug is only showing when we don't take reaction on the monitored output (like a remote anchor)
09:56 < BlueMatt> wait, elaborate?
09:58 < ariard> wait, let me check master post-649 how do we register watched output
09:59 < BlueMatt> its via the Filter thing, but the ChannelMonitor now always filters the block on block_connected
09:59 < BlueMatt> I *think* the right thing would be an assertion in ChannelMonitor::filter_block/spends_watched_output that the filter data is correct
10:00 < BlueMatt> eg the script_pubkey matches
10:01 < BlueMatt> (or if there's something else I'm missing, either way we should assert there that everything matches, cause that path is called everywhere)
10:02 < ariard> you say not the Filter always filter on scriptpubkey ?
10:02 < BlueMatt> hmm?
10:02 < BlueMatt> I'm saying the only filter logic we have in the codebase now is ChannelMonitor::filter_block
10:02 < BlueMatt> otherwise users have to do chain::Filter manually
10:03 < BlueMatt> (I think, though maybe we should *also* test that, but I'm less worried about that)
10:03 < ariard> so we're guaranteeing to return any commitment children txn ?
10:03 < BlueMatt> yes.
10:03 < BlueMatt> I though we'd agreed to that :)
10:04 < BlueMatt> (docs may still need to be cleaned up/updated, but, yes)
10:05 < ariard> yes ofc we agree on this, but that let me thinks it might solve the bug
10:05 < BlueMatt> hmmm....i doubt it? we only require any children tx *in the same block*
10:05 < BlueMatt> so if they're split across blocks we have to always update filter
10:08 < ariard> and now we do the filtering manually in the test framework
10:08 < ariard> what we should is modify the chain::Filter in test_utils to assert that the passed index is the *right* one
10:08 < BlueMatt> vaguely, yes, though ChannelMonitor does a filter run right before it processes a block.
10:09 < BlueMatt> yes, i think it would be equivalent to do so in ChannelMonitor::filter_block, no?
10:09 < ariard> the requirement of register_output is to filter on outpoint+scriptpubkey or scriptpubkey only ?
10:09 < ariard> I think it's free to the implementor
10:09 < BlueMatt> yes, its either, or both, or whatever user wants to do
10:09 < ariard> the issue isn't in ChannelMonitor::filter_block here
10:10 < BlueMatt> right, I guess I forgot where the issue is
10:11 < ariard> or it is ? because it also do enumerate
10:12 < ariard> okay I see how to write a test to trigger it by manually building the commitment transaction, I think
10:12 < BlueMatt> right, ChannelMonitor::filter_block *should* be doing the same filtering that a user could do, if they're filtering
10:12 < BlueMatt> at least araiu
10:12 < BlueMatt> awesome
10:55 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined #rust-bitcoin
10:56 < jeremyrubin> from ##miniscript:
10:56 < jeremyrubin> [10/5/20 10:29] <jeremyrubin> Would anyone have any feelings about implementing https://graham.cool/schemars/ across the rust-bitcoin packages?
10:56 < jeremyrubin> [10/5/20 10:31] <jeremyrubin> It's super useful to be able to export a descriptor of a JSON type when using serde json serialization for generic UX code for example.
10:56 < jeremyrubin> [10/5/20 10:35] <jeremyrubin> it should be possible to make it optional
10:59 < ariard> jeremyrubin: see notmandatory I guess he might be interested, bdk is aiming to integrate in-depth with descriptors
10:59 < ariard> BlueMatt: hmmmm sounds broken https://github.com/ariard/rust-lightning/pull/new/2020-09-demo-bugs
10:59 < ariard> bbl, gonna catch coffee before meeting in one hour
11:01 < BlueMatt> jeremyrubin: can we not just use serde? we already have optional serde support and it sounds like that would be compatible and require fewer new dependencies
11:01 < BlueMatt> ariard: will look thanks!
11:01 < jeremyrubin> schemars generates schemas not serializations
11:02 < jeremyrubin> schemars is compat with serde
11:02 < jeremyrubin> E.g., schema_from!(struct Example { i : u32 }) == "{'i' : number}"
11:02 < jeremyrubin> (or something like that)
11:03 < BlueMatt> ah, ok, looks like it could just be done once and then checked into git? that would imply no new (runtime) dependencies?
11:03 < jeremyrubin> No
11:04 < jeremyrubin> Because you need to be able to generate schemas for downstream structs
11:04 < BlueMatt> ?
11:04 < jeremyrubin> e.g., struct My { amounts : [Amount; 32] }
11:04 < BlueMatt> are they not nestable?
11:04 < jeremyrubin> They are!
11:04 < BlueMatt> but it needs the annotations to generate them? yeesh that blows
11:05 < jeremyrubin> Well it works the same way serde works
11:05 < jeremyrubin> You generate a trait
11:05 < jeremyrubin> and then you use that trait if you want to
11:05 < BlueMatt> right. sucks, though, that it cant figure it out from the serde traits given it claims to be compatible with serde
11:05 < jeremyrubin> It's compatible in that it will generate a matching schema to serde's json output\
11:06 < BlueMatt> yes, i understood that
11:06 < jeremyrubin> Serde-json could be patched maybe to depend on schemars :p
11:06 < BlueMatt> just sucks it cant rely on the serde stuff, is my point
11:06 < jeremyrubin> that's a serde problem
11:06 < BlueMatt> lol that sounds like a terrible idea
11:06 < jeremyrubin> anyways it can be derived behind a cfg flag
11:07 < jeremyrubin> so shouldn't affect anyone who doesn't want it too much
11:07 < BlueMatt> right. sucks that thats the only way but I dont really care *too* much if its just some feature flag
11:07 < jeremyrubin> It can also be done (at great inconvenience) through serde remote crate
11:07 < BlueMatt> not my maintinence burden :p
11:08 < jeremyrubin> but it gets pretty tricky to make that work maitenance wise
11:09 < BlueMatt> anyway, sounds like between you and andytoshi if he wants to take the maintinence burden of it.
11:09 < BlueMatt> though I imagine it can be used once to generate (by downstream crates) and then not pulled as a runtime dependency in practice?
11:10 < BlueMatt> I mean I cant imagine anyone would want/need to pull such a thing as a runtime dependency period.
11:10 < jeremyrubin> For the most part it's compile time
11:10 < jeremyrubin> But you need it at compile time for dependencies as well
11:10 < BlueMatt> rightright
11:10 < jeremyrubin> you can't (afaik) just stick a static string generated one time
11:11 < jeremyrubin> (also you would cause hell if those ever diverged)
11:12 < jeremyrubin> You could just hand write the schemas, but you'd have no guarnatees about what serde does
11:12 < jeremyrubin> e.g., is Array<Amount> -> [{amount: number}] or [number]
11:12 < BlueMatt> sure, i mean we do things like have a script to build, then check in CI that the latest version is in git, which sounds like you could do that here.
11:12 < BlueMatt> just could only do so downstream
11:13 < jeremyrubin> The above example is why it wouldn't work
11:13 < jeremyrubin> you need the whole type because serde can do things with inlining arrays
11:13 < jeremyrubin> unless you pregenerate all sorts of container schemas or something
11:13 < jeremyrubin> which is starting to sound like more work then just doing the thing
11:13 < BlueMatt> I...dont think you're understanding what I'm saying
11:13 < BlueMatt> but it also doesnt matter much
11:13  * BlueMatt -> lunch
11:14 < jeremyrubin> I think I understand exactly what you're saying, but I'm fairly confident that would be broken in a number of non-obvious ways
11:15 < BlueMatt> I'm not suggesting anything different from what you're proposing, only that if a downstream user wants to use this feature that *they* would, I imagine, generate once and then use CI to keep it up to date instead of taking another dependency on a third-party crate for runtime builds.
11:15 < BlueMatt> presumably CI would have no problem making sure a hardcoded string matches exactly what a script generates.
11:18 < jeremyrubin> In either case the way to do this is identical, you add cfg flags to the upstream crates with the JsonSchema derive macro
11:19 < jeremyrubin> A downstream user can choose to either do what you're saying or not
11:19 < BlueMatt> yes, thats what I said :)
11:19 < jeremyrubin> It should work, but is super inconvenient because you could need to generate schemas for random types that only exist within generic functions
11:19  * BlueMatt -> lunch
11:20 < jeremyrubin> ttyl
11:21 < jeremyrubin> e.g., something that returns a Vec<Result<Option<(A, B)>, Error>> can automagically generate a schema when needed which is amazing, but with this approach you would have to hand-unroll (or maybe with some proc mac that writes files?? idunno) every place you ever need a schema
11:28 < BlueMatt> the price of being secure against dependency attacks :shrug:
11:32 < jeremyrubin> I think from what I can tell fortunatley the only new dep is the crate itself, the others are already included in rust-bitcoin. So it's one crate to pin & audit.
11:34 < jeremyrubin> ah and dynclone
12:13 -!- tyler [~varioust@161.35.105.37] has joined #rust-bitcoin
12:14 -!- tyler [~varioust@161.35.105.37] has quit [Client Quit]
12:14 -!- varioust [~varioust@161.35.105.37] has joined #rust-bitcoin
12:57 -!- varioust_ [~varioust@rrcs-76-79-47-154.west.biz.rr.com] has joined #rust-bitcoin
12:58 -!- varioust [~varioust@161.35.105.37] has quit [Ping timeout: 240 seconds]
12:58 -!- varioust_ is now known as varioust
13:19 -!- jkczyz_ [sid419941@gateway/web/irccloud.com/x-anszanoxiedqhnvw] has joined #rust-bitcoin
13:21 -!- real_or_- [~real_or_r@173.249.7.254] has joined #rust-bitcoin
13:23 -!- b10c_ [~b10c@2a01:4f8:192:612a:216:3eff:fef3:dc6a] has joined #rust-bitcoin
13:25 -!- real_or_random [~real_or_r@2a02:c207:3002:7468::1] has quit [Ping timeout: 244 seconds]
13:25 -!- jkczyz [sid419941@gateway/web/irccloud.com/x-hcvvptwtteadyimp] has quit [Ping timeout: 244 seconds]
13:25 -!- moneyball [sid299869@gateway/web/irccloud.com/x-knmkcntuccvblapy] has quit [Ping timeout: 244 seconds]
13:25 -!- b10c [~b10c@2a01:4f8:192:612a:216:3eff:fef3:dc6a] has quit [Ping timeout: 244 seconds]
13:25 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 244 seconds]
13:25 -!- nothingmuch [~nothingmu@unaffiliated/nothingmuch] has quit [Ping timeout: 244 seconds]
13:25 -!- jkczyz_ is now known as jkczyz
13:26 -!- somethinglittle [~nothingmu@unaffiliated/nothingmuch] has joined #rust-bitcoin
13:27 -!- moneyball__ [sid299869@gateway/web/irccloud.com/session] has joined #rust-bitcoin
13:27 -!- moneyball__ [sid299869@gateway/web/irccloud.com/session] has quit [Changing host]
13:27 -!- moneyball__ [sid299869@gateway/web/irccloud.com/x-epbknxfxacmkodvz] has joined #rust-bitcoin
13:28 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined #rust-bitcoin
13:45 -!- somethinglittle is now known as nothingmuch
14:09 -!- varioust [~varioust@rrcs-76-79-47-154.west.biz.rr.com] has quit [Ping timeout: 240 seconds]
14:21 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:cd28:750c:410c:649a] has joined #rust-bitcoin
14:50 -!- tibo [~tibo@2400:4050:2a83:7000:31e5:4ab5:9286:ab4c] has joined #rust-bitcoin
14:51 -!- Mylene60Pollich [~Mylene60P@static.57.1.216.95.clients.your-server.de] has joined #rust-bitcoin
14:52 -!- tibo [~tibo@2400:4050:2a83:7000:31e5:4ab5:9286:ab4c] has quit [Remote host closed the connection]
15:17 -!- jamesob [sid180710@gateway/web/irccloud.com/x-pmxtvqdyysmhmxas] has quit [Ping timeout: 272 seconds]
15:17 -!- jamesob [sid180710@gateway/web/irccloud.com/x-qmddwxzkygwjtpel] has joined #rust-bitcoin
15:34 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:cd28:750c:410c:649a] has quit []
16:38 -!- tibo [~tibo@2400:4050:2a83:7000:488a:476e:8242:aa61] has joined #rust-bitcoin
17:00 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
17:05 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin
17:20 -!- varioust [~varioust@cpe-108-167-11-88.neb.res.rr.com] has joined #rust-bitcoin
18:03 -!- varioust [~varioust@cpe-108-167-11-88.neb.res.rr.com] has quit [Ping timeout: 265 seconds]
18:11 -!- varioust [~varioust@cpe-108-167-11-88.neb.res.rr.com] has joined #rust-bitcoin
19:00 -!- varioust [~varioust@cpe-108-167-11-88.neb.res.rr.com] has quit [Quit: varioust]
19:01 -!- varioust [~varioust@cpe-108-167-11-88.neb.res.rr.com] has joined #rust-bitcoin
19:16 -!- varioust [~varioust@cpe-108-167-11-88.neb.res.rr.com] has quit [Ping timeout: 240 seconds]
19:22 -!- varioust [~varioust@cpe-108-167-11-88.neb.res.rr.com] has joined #rust-bitcoin
19:31 -!- tibo_ [~tibo@2400:4050:2a83:7000:803e:5937:d7cc:3b68] has joined #rust-bitcoin
19:33 -!- tibo [~tibo@2400:4050:2a83:7000:488a:476e:8242:aa61] has quit [Ping timeout: 240 seconds]
20:09 -!- varioust [~varioust@cpe-108-167-11-88.neb.res.rr.com] has quit [Ping timeout: 256 seconds]
23:05 -!- Netsplit *.net <-> *.split quits: cloudhead, kallewoof, wallet42__
23:05 -!- Netsplit over, joins: cloudhead
23:05 -!- wallet42__ [sid154231@gateway/web/irccloud.com/x-ddsrglszoalcxslt] has joined #rust-bitcoin
23:10 -!- kallewoof [~quassel@240d:1a:759:6000:a7b1:451a:8874:e1ac] has joined #rust-bitcoin
--- Log closed Tue Oct 06 00:00:38 2020