didn't we change to travis-ci.com already?

hmm looks like no

luigi1111w: we wanted to change to travis-ci.com once issues showed up again

so now?

selsta: ok, 6757 approved

.merges

Did we want to use this for this version release? monero-project/meta #489

Should be done AFAICT

yep

Ok I'll go ahead and close the issue -- should I make a new one for this release with the checklist, or is there another preferred way to run with this?

Probably would be best on a kanban board or something similar to part out tasks.

github issue sounds fine

Ok, converting it to an actual MD checklist then will post

luigi1111w: Snipa: please revert 921dd8dde5d381052d0aa2936304a3541a230c55, it breaks passwords

Looks like the tests are missing something, as selsta indicates this breaks on multiple wallets

Need to investigate further before deploying

That feature isn't security-critical, and can wait

selsta: had you done a save on the wallets with the new commit before loading the wallets on the previous commit?

no

At any rate, reverting is the safest option since this would affect user key data

can try that

Please do

Load with new commit, save with new commit, load with old commit

Right now it sounds like you loaded with new commit, killed the wallet application, and loaded with old commit successfully?

even with save I can still load it in old version fine

OK, that's good

(I'm still investigating with test wallets from selsta)

but still, reverting is safest since this is non-consensus and involves user data

it's also not security critical

You will need to make a revert PR.

You == sarang?

Somebody. But I'd vote for sarang.

Vote early, vote often.

o_0

git revert 921dd8dde5d381052d0aa2936304a3541a230c55

Or something.

luigi can do it without PR too :D

or did it in the past when we broke gui

git is great until it's not :/

And mess with mooo's git history ?

no

just normal revert pr

commit*

\_o< >o_/

no force push

selsta: have you also commented on the (closed) PR on github?

If not, please do, for completeness

ok

thanks

Testing the reversion locally now

I can revert if you prefer

go ahead

I've made a wekan (basically kanban) board for the upcoming fork, and am adding in all tasks/sub-tasks: monero.sandcats.io/grain/A3LjpvoHxf…-for-v0-17-0-0-hard-fork-10-17-2020

done

Any devs here been keeping an eye on the atomic swap paper? I assume almost all have been, looking for a bit more involved. As in, actually considering an implementation.

h4sh3d: is the one who has been doing the vast majority of the work on it AFAIK

<sethsimmons "I've made a wekan (basically kan"> Please let me know if you all can/cannot access this, we should probably start assigning out task ASAP/people start taking tasks on

Oh. Yeah. I already reached out to him. He's on vacation.

#monero-research-lab:matrix.org

is the better place to ask about that IIRC

#monero-research-lab on IRC, didn't mean to mention the Matrix channel :P

It's a very interesting writeup, to be sure

Well, not looking to discuss theory, so unless this is limited to discussion about monerod... I already have an impl of the protocol up. Working on the XMR file now. I have crafted XMR TXs before, so I should be able to do it, but I'm looking for someone I can PM in a bit more depth

What sort of implementation?

Proof of Concept in Rust published on GitHub and verified via BTC-MR (ed25519 unscripted coin; personal project of mine)

Might you link it here?

Should also have a Nano file in a few days.

ty

I do know monero-rs exists. Beyond looking for someone I can ping more targeted questions off of, without spamming here, I also wanted to see if they'd be interested in reviewing the codebase (not a full audit, but a checkup)

The usual disclaimer of "preprints need not have undergone any kind of external review" should be mentioned here

So any implementation carries risk

Oh. I did fully state it's not audited, use at your own risk. The BTC file only uses the Testnet/Regtest network bytes. I didn't add a switch to carry to mainnet.

Unless you're referring to the paper itself, in which case I have looked over that.

I'm not looking to get this published at a college. Just establish a PoC that can feasibly be turned into a library/app.

The latest writeup of the protocol has not undergone review AFAIK

I just want to make that abundantly clear

Yeah. I understand there's a chain of lack of review here.

I do explicitly label this a PoC, don't support any mainnet, and so on and so on. I'm not trying to build a DEX out of this, or even a full app. I do want to 'finish' the PoC though.

Which means adding the XMR file and checking if someone wants to look over the code side of things.

Oh, this is for BTC and another ed25519-based transaction protocol?

Anyways. Just looking for a XMR-knowledgeable dev who may be interested in helping out via advice/some glances. I'm sure a CCS proposal will turn up at some point for audits/another implementation/something similar, so it's not something I feel is urgent.

Any unscripted Ed25519 coin.

Ah I see

If you ignore view key, which isn't used by other protocols, the protocol directly carries

So we did implement the full protocol with enough abstraction to support adding in the view key.

Sure, the swap protocol is pretty general and not specific to the Monero protocol

But despite being designed for XMR, the protocol has a lot more applications which we wanted to enable

Especially since, in full transparency, the initial target for this library is my project and my partner is a former Nano developer who's planning on submitting that file. I've already done the bare bones of XMR on my end.

And then we also abstracted the BTC side.

We may have over-engineered it just a bit for a PoC...

Would all those working on this release and wanting access to the Wekan board for this release please DM me? This is probably the easiest way for us to assign out/ensure we get everything knocked out on time for this release.

You can view the board here, and I will grant edit to those who need it: monero.sandcats.io/grain/A3LjpvoHxf…-for-v0-17-0-0-hard-fork-10-17-2020

Don't want random people in here messing with the list so don't want to share the edit URL directly here.

<sethsimmons "Would all those working on this "> Nevermind, edit is broken right now, trying to sort it out.

For the record, the updates TXT record does not have "source". I was waiting to get pinged to check it worked, and it didn't :)

no hash because I didn’t build the source archive for the past releases

np, most people using source will likely know when to update anyway.

will try to think about it for next release

Shall I PR a revert for the in-memory encryption change, it doesn't seem to have been done yet ?

Oh, nevermind, there's a commit without PR. I should have checked that first.

luigi1111 said they'd done it