01:16:45 <UkoeHB> update about fund burning issue: https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024?permalink_comment_id=4199659#gistcomment-4199659
02:25:14 <nikg83[m]> <UkoeHB> "update about fund burning issue:..." <- This bug is on current mainnet?
02:35:29 <UkoeHB> nikg83[m]: https://github.com/monero-project/research-lab/issues/103
03:03:02 <UkoeHB> it's not really a bug, just a really old sub-optimality
03:15:05 <wernervasquez[m]> 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)?
03:36:06 <UkoeHB> wernervasquez[m]: you can make two outputs with the same onetime address, only one of them can be spent
03:36:46 <UkoeHB> wallets currently deal with it by only trying to spend the output with the highest amount
03:37:36 <UkoeHB> 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)
03:38:36 <UkoeHB> 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?
03:50:36 <wernervasquez[m]> 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?
04:30:47 <UkoeHB> wernervasquez[m]: that would break tx chaining because you could maliciously block any offchain work-in-progress tx
12:47:18 <kayabanerve[m]> <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.
12:48:20 <kayabanerve[m]> It'd be a DoS against any transaction in the mempool, not just off-chain WIP TXs (though those are ofc easier to frontrun).
14:43:02 <UkoeHB> new paper with bold claims https://eprint.iacr.org/2022/744
14:49:46 <spirobel[m]> <UkoeHB> "new paper with bold claims https..." <- what do you think about it?
14:50:16 <spirobel[m]> * about it? looks interesting
14:53:37 <UkoeHB> have not read much and too busy today
14:53:48 <UkoeHB> but if the claims hold up, seems promising
14:59:31 <moneromooo> Look for "ethereum" in it. I'm unsure if they rely on using that on the side for some reason.
14:59:58 <moneromooo> It'd make no sense, but they do mention it a number of times, and not as a "see also".
15:00:47 <moneromooo> 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)
15:01:16 <moneromooo> I'm hoping it's "it can also work on ethereum", but it's unclear so far.
15:02:32 <UkoeHB> > The number of on-chain transactions. Establishing a channel requires 1 transaction on Monero and Ethereum respectively,
15:02:44 <UkoeHB> looks like they are using ethereum for a core piece
15:03:58 <ooo123ooo1234567> 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
15:05:08 <UkoeHB> finally a good use for ethereum? :p
15:06:10 <ooo123ooo1234567> "However, AuxChannel is a generic construction that cannot be applied to Monero directly ... " so it's slight modification of AuxChannel
15:06:29 <ooo123ooo1234567> "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
15:06:34 <ooo123ooo1234567> s/papeg/paper/
15:06:40 <ooo123ooo1234567> true academic approach
23:35:43 <kayabanerve[m]> It also requires tx chaining
23:36:51 <kayabanerve[m]> 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
23:38:02 <kayabanerve[m]> Right. The pre-sig is an adaptor sig. It requires creating one for a secondary tx
23:38:50 <kayabanerve[m]> 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
23:39:13 <kayabanerve[m]> Rucknium: am I insane for expecting that level of due diligence?
23:40:00 <kayabanerve[m]> I understand why this assumption is made. I don't get they don't reach out nor have someone suitable directly working with them
23:41:59 <kayabanerve[m]> Or is this considered a preprint and us only commenting after it's published as a preprint is the process?
23:42:24 <ooo123ooo1234567> kayabanerve[m]: wow
23:43:25 <UkoeHB> it was added to the eprint archive 4 days ago, you could probably email them with feedback
23:43:25 <kayabanerve[m]> 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
23:43:41 <kayabanerve[m]> ooo123ooo1234567: It's not that I don't appreciate the effort. I don't appreciate the lack of
23:44:06 <kayabanerve[m]> The paymo author made another paper which successfully would've created a payment channel for monero
23:44:25 <kayabanerve[m]> I think it's a theoretical statement without practical value, but I appreciate it :)
23:45:20 <kayabanerve[m]> 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
23:46:07 <kayabanerve[m]> 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
23:46:42 <kayabanerve[m]> 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
23:46:50 <kayabanerve[m]> Or simply moved to its components
23:47:07 <kayabanerve[m]> I'm not even saying we shouldn't archive it
23:48:00 <kayabanerve[m]> But also, how bad will it look on them to recall a paper?
23:56:01 <ooo123ooo1234567> finally something on topic