update about fund burning issue: gist.github.com/tevador/50160d160d2…ment_id=4199659#gistcomment-4199659

<UkoeHB> "update about fund burning issue:..." <- This bug is on current mainnet?

nikg83[m]: monero-project/research-lab #103

it's not really a bug, just a really old sub-optimality

UkoeHB: it has been a while since I have looked at the burning bug. Can you refresh my memory on this point? Can a third party detect a that a transaction was maliciously constructed? Or does it require the private keys (or a signature made with those keys)?

wernervasquez[m]: you can make two outputs with the same onetime address, only one of them can be spent

wallets currently deal with it by only trying to spend the output with the highest amount

You can’t reliably identify malicious txs, since the first tx that enters the chain isn’t necessarily honest (ie you can frontrun an honest tx)

Signing with the tx privkey would identify some malicious events, but what about a sender who burns his own output just to spite the recipient?

UkoeHB: Why not just disallow duplicate one time addresses at the consensus level? Why should the network accept a transaction with a duplicate one time address?

wernervasquez[m]: that would break tx chaining because you could maliciously block any offchain work-in-progress tx

<UkoeHB> "it's not really a bug, just a..." <- It's a bug that affects a lot of wallet software due to their failure to handle this case successfully.

It'd be a DoS against any transaction in the mempool, not just off-chain WIP TXs (though those are ofc easier to frontrun).

new paper with bold claims eprint.iacr.org/2022/744

<UkoeHB> "new paper with bold claims https..." <- what do you think about it?

* about it? looks interesting

have not read much and too busy today

but if the claims hold up, seems promising

Look for "ethereum" in it. I'm unsure if they rely on using that on the side for some reason.

It'd make no sense, but they do mention it a number of times, and not as a "see also".

ie, The number of on-chain transactions. Establishing a channelrequires 1 transaction on Monero and Ethereum respectively,and no on-chain transaction is required on both Monero andEthereum for processing an off-chain payment (updating the channel)

I'm hoping it's "it can also work on ethereum", but it's unclear so far.

> The number of on-chain transactions. Establishing a channel requires 1 transaction on Monero and Ethereum respectively,

looks like they are using ethereum for a core piece

UkoeHB: "We employ a distributed Key Escrow Service following AuxChannel paradigm [7] to provide the guaranteed channel closure, guaranteed payout and unlockability properties. Key Escrow Service can be implemented on a script-enabled platform, for example on Ethereum." indeed

finally a good use for ethereum? :p

"However, AuxChannel is a generic construction that cannot be applied to Monero directly ... " so it's slight modification of AuxChannel

"This work addresses this unclear design and provides a formal security model and analysis for our proposed system." plus a lot of formal things to justify usefulness of the papeg

s/papeg/paper/

true academic approach

It also requires tx chaining

Unless they're creating a "pre-signature" which has nothing to do with the monero tx, despite written as over it, yet solely one which leaks the private key

Right. The pre-sig is an adaptor sig. It requires creating one for a secondary tx

How tf have we now had multiple academic papers about monero where no one from the research team ever talks to us and they don't actually understand how monero works

Rucknium: am I insane for expecting that level of due diligence?

I understand why this assumption is made. I don't get they don't reach out nor have someone suitable directly working with them

Or is this considered a preprint and us only commenting after it's published as a preprint is the process?

kayabanerve[m]: wow

it was added to the eprint archive 4 days ago, you could probably email them with feedback

If it takes me five minutes to say it's improperly defining proofs and ten minutes to say it's impossible, it just feels like it's a waste of time

ooo123ooo1234567: It's not that I don't appreciate the effort. I don't appreciate the lack of

The paymo author made another paper which successfully would've created a payment channel for monero

I think it's a theoretical statement without practical value, but I appreciate it :)

But this names monero and is premised on being a solution for monero when the people who actually know what monero is weren't involved

It's like if ruck tells me about stats and I say I solved a problem, despite no knowledge of stats, which I don't actually solve because I don't understand the problem

This paper probably does have value. It's just invalid as is and needs to be moved to a theoretical currency or reformatted as its components with a new use case in mind

Or simply moved to its components

I'm not even saying we shouldn't archive it

But also, how bad will it look on them to recall a paper?

finally something on topic