I will be either unavailable until Monday, or will write from a secondary nickname.

How to delete subaddress in monero gui?

You'd clear its label I think.

If only one of you gave Papa ChooChoo some TLC when I wrote a faster miner, instead of ignoring him, things could have happened differently np.reddit.com/r/Monero/comments/5lsfgt/_/dbz0jnp

Why is the monero repository locked to contributors only?

I cannot comment on an issue

Because some asshole is spamming issues/PRs/comments every few hours.

fluffypony: ^

People just trying to shit up the world... What a life it must be...

ah I suspected it

moneromooo this the log you asked me btw pastebin.com/raw/JDLWjKnC

Thanks

I think the best we can do here, since this is the mmap support test, is to proceed. I'll have patch for you in a few minutes, just checking it builds.

Hopefully all the other filesystem things are implemented...

That for loop at the end, shouldn't it only remove unspent keyimages until the transaction input that caused the stop?

spent*

Yes, but the txn will be aborted anyway, so what it does doesn't actually matter AFAICT.

So it removes all it's done so far, plus stuff it hasn't yet done.

But what if that stuff it hasn't yet done is actually a double spend?

The validation that goes before calling any of these functions is quite stringent, so an unknown input type should never even reach this code but that might not be  the case in the future.

Your question ("what it...") is way too open ended. Ask a more precise question.

Assume a transaction with the following transaction input types: [ unknown type, double spend txin_to_key ], the reverting logic in the for loop would cause the second element which was an attempted double spend to have its keyimage removed from the database.

AFAICT this code is the code responsible for double spend prevention. The add_spent_key would fail on a double spend and throw an error.

Ah. And the function returns void rather than an error or an exception. Good point.

Adding a throw there (and getting rid of the removals) probably hardens this.

That add_transaction() is called by add_block(), which means this function is the only double spend prevention code at the moment.

Hrm. Plausible enough so far.

It will never pass transaction validation though, but it's worth hardening it since it seems pretty critical.

Do you agree that throwing in that function (instead of just return;) would fix it ?

(and not bothering with removing)

I don't know enough about the monero codebase to make such assesment, I'm just a security researcher. You don't ask a bulldozer to build your house hehe.

OK, I'm pretty sure it's enough :)

Always good to make sure though. Is "NeighbourlyGuy" OK for credit for the report in the commit message ?

Ahh, I just typed in a random name, I'm from keyboardwarrior.be, but putting in KeyboardWarrior is good enough.

Got it, thanks.

No problem, thank you as well.

Patched, I'll PR after tests pass, just in case. Thanks.