03:08:02 <sgp_> sarang: Thorchain is expecting to use multisig. They modified the Monero wallet to include parallel generation https://gitlab.com/thorchain/tss/monero-sign
03:09:26 <sgp_> this sort of RPC functionality is going to need to be better integrated to the extent possible since I know a few projects plan to run with this implementation
07:27:07 <dEBRUYNE> sgp_: Is this referring to the Triptych research sarang is conducting?
13:18:27 <sgp_> dEBRUYNE: yeah
13:19:26 <sgp_> looks like Thorchain is doing some pretty interesting things, but also that it could have inadvertent effects on the network. Some initial context first:
13:19:49 <sgp_> They modified the Monero wallet to add additional RPC commands for multisig wallets. You can see that here: https://gitlab.com/thorchain/tss/monero-sign
13:20:33 <sgp_> Then, they are hoping to require users to send transactions to Thorchain using a long tx_extra string
13:21:41 <sgp_> I've been speaking with them for a few hours trying to figure out how to solve this out of band so they don't have to use tx_extra, but they are shooting down many of the other ideas. They seem intent on wanting to use it
13:22:06 <sgp_> I will keep trying to come up with something else that works for them
13:22:31 <moneromooo> Is this a bullshit use or an actual interesting use of extra ?
13:23:26 <sgp_> it's the simplest way to integrate what they want to do for an actual use-case, so it's not totally bullshit. But there are should be cleverer ways to communicate without using tx_extra
13:23:42 <moneromooo> But what do they want to do ? :)
13:24:26 <sgp_> they want the sender of the transaction to indicate their intent in the transaction itself, since the recipient is a consortium of nodes that need to be able to verify that the other nodes are acting non-maliciously
13:25:18 <sgp_> tx_extra would look like ADD:XMR.XMR:<thorchain_address>
13:25:25 <moneromooo> How much data in the intent ?
13:26:32 <sgp_> ADD:XMR.XMR:thor1krcz33mejvc5f6grj2c5w5x3kuj7mnjhgqltj8
13:26:37 <sgp_> ADD:XMR:thor1krcz33mejvc5f6grj2c5w5x3kuj7mnjhgqltj8
13:26:44 <sgp_> examples would be the two above
13:26:51 <sethsimmons> Encrypted or plaintext?
13:27:02 <sgp_> plaintext probably
13:27:04 <moneromooo> Are ADD and XMR placeholders ? If so, 3 chars each ?
13:27:04 <sethsimmons> oof
13:28:04 <sgp_> the format they use is `ADD:XMR:XMR`, but since XMR is the base asset, they are open to shortening it to `ADD:XMR`
13:28:47 <sgp_> for adding BTC liquidity it would look like `ADD:BTC:<thorchain_address>`
13:29:03 <sgp_> except Bitcoin can't store that much info either
13:29:09 <moneromooo> One can plonk encrypted 32 bytes in a BP+. 8 bytes in an encrypted pid.
13:29:36 <moneromooo> The "thorchain_address" is 32 bytes I assume ?
13:31:14 <sgp_> I'm confirming
13:32:43 <moneromooo> (there's no tooling atm for BP embedding, but I'd want to do that anyway)
13:36:42 <sgp_> the address string looks longer than 32 bytes no? thor1krcz33mejvc5f6grj2c5w5x3kuj7mnjhgqltj8
13:38:28 <sgp_> 43 bytes? 39 without the `thor`?
13:39:03 <moneromooo> Decoded, obviously.
13:39:35 <moneromooo> Like monero addresses are 64 bytes but the user address is like 98 chars or whatever.
13:39:39 <moneromooo> keys.
13:41:03 <sgp_> ah, I'm too dumb to know this stuff
13:41:57 <sgp_> there are 2 main commands: `ADD` and `SWAP`
13:42:44 <sgp_> `SWAP` would look like `SWAP:CHAIN.ASSET:DESTINATION:LIMIT:AFFILIATE:FEE`
13:43:06 <sgp_> so there's quite a bit of text there
13:43:13 <sgp_> eg: `SWAP:THOR.RUNE:tthor1zpa4c6zpa4cyz9s93xuje2pwkswsqzn2zpa4c:3141441780:tthor1ql2tcqyrqsgnql2tcqyj2n8kfdmt9lh0yzql2tcqy:10`
13:45:57 <Inge-> transactions are so cheap you just send a dozen
13:47:21 <sgp_> they definitely can send this data with tx_extra, but obviously I would like a way around that
13:47:41 <sgp_> and they don't really want to complicate everything on their end where possible
13:50:18 <moneromooo> Well if this becomes used, the addresses seem to be a good way to link monero txes, so that'd be a very good reason to kill extra once and for all.
13:50:29 <moneromooo> Kinda sad about it though.
13:51:53 <sgp_> fwiw, they will leak all info anyway with the receiving monero wallet, which will publicly share view keys and key images
13:52:14 <moneromooo> Oh, evil bastards...
13:55:52 <sgp_> leaving aside tx_extra for now, let's talk about multisig
13:56:06 <sgp_> this is where an expert will need to review what they have done
13:56:18 <sgp_> they modified the C++ code to add new RPC commands https://gitlab.com/thorchain/tss/monero-sign
13:56:57 <sgp_> sign_multisig_parallel, export_sigkeys, accumulate_multisig, check_transaction, save_pool_wallet
13:58:36 <sgp_> who would know how to look at this? rbrunner ? vtnerd ?
13:59:29 <UkoeHB> current monero multisig code uses 'round robin' signing, where signers have to send serial messages; however 'aggregation' signing is more efficient - a more 'parallel' approach; they could be using this in thorchain
14:00:47 <sgp_> Yeah that's my understanding - they are using a more parallel approach
14:01:10 <UkoeHB> the concept is legit, idk about their implementatin
14:02:57 <sgp_> Is this something we should try to add to the main codebase
14:03:11 <sgp_> Someone would need to review theirs
14:05:16 <sgp_> ugh I can't even comment here, this is annoying af https://github.com/monero-project/monero/issues/6668
14:08:55 <gingeropolous> ugh tx_extra. sgp_ , pastebin what you wanted to post on the thread and i or someone can copypasta
14:10:53 <UkoeHB> Yes multisig needs several updates https://github.com/monero-project/research-lab/issues/67
14:13:45 <sgp_> gingeropolous: https://paste.mozilla.org/LXSOF9RG
14:16:52 <gingeropolous> done: https://github.com/monero-project/monero/issues/6668
14:17:11 <sech1> are tx extra not encrypted at all?
14:17:20 <gingeropolous> correct
14:17:32 <gingeropolous> its just cleartext, anything goes
14:19:02 <sech1> and max length is 255 bytes, interesting. I need to spam some stuff for eternity before too late :)
14:21:09 <gingeropolous> sech1, i think the max length was enforced due to deadbeef https://xmrchain.net/tx/fba62a80ff85021671227b25035fa809973bae29b2b93479c433d4d3ab99ec48
14:23:15 <sech1> mining pools use tx_extra to distribute work between miners
14:23:48 <sarang> FWIW someone _could_ choose to encrypt that data, but it's not enforced by consensus (and can't be if intended to be private to a recipient)
14:24:13 <gingeropolous> i think we can hack it such that coinbase can still use tx_extra , would address mining pool issue
14:24:32 <hyc> wait what? how do mining pools distributed work with tx_extra?
14:24:42 <gingeropolous> i think sech1 meant payments
14:24:43 <hyc> they're not generating txs except on payouts?
14:24:50 <sech1> extra_nonce field
14:25:04 <sech1> You can't just have 10,000 miners using the same 32-bit nonce space
14:25:23 <sgp_> this is the first I'm hearing of mining pools using this
14:25:42 <sech1> every connected woker gets their unique extra_nonce
14:25:54 <endor00[m]> <sgp_ "this is the first I'm hearing of"> you mean pools using extra_nonce?
14:26:04 <endor00[m]> Been there since bitcoin
14:26:05 <sech1> All pools use this, ask Snipa or M5M400
14:26:18 <sgp_> it's on me that I didn't know, but I am just now learning yeah
14:26:54 <endor00[m]> Can't have it any other way, since you only have 4 billion nonces before having to switch to a new block template
14:27:04 <hyc> extra_nonce is in block header, not per-txn
14:27:05 <hyc> ??
14:27:21 <sech1> extra_nonce is a part of tx_extra in miner reward tx
14:27:22 <moneromooo> You could regen the ouput per miner :)
14:27:50 <sech1> this is how I can fingerprint mining pools and even solo miners
14:28:24 <endor00[m]> The xmrig-proxy splits the nonce range using the top 8 bits on the other hand, right?
14:28:35 <sech1> yes
14:28:44 <sech1> it creates new connection to the pool per each 256 workers
14:29:01 <sech1> NiceHash does the same
14:29:16 <gingeropolous> <sech1> extra_nonce is a part of tx_extra in miner reward tx >> hrm, and the miner reward tx is NOT the coinbase huh.
14:29:55 <hyc> ??
14:30:31 <sech1> it is coinbase
14:31:10 <moneromooo> How do you know ? Is monero anon so bad you can tell ?
14:32:46 <sech1> https://github.com/monero-project/monero/blob/master/src/cryptonote_core/cryptonote_tx_utils.cpp#L79
14:32:55 <sech1> and line 87 there
14:41:57 <hyc> still not getting it. extra_nonce is an input to getblocktemplate
14:42:07 <hyc> that's not per-tx
14:42:22 <hyc> so what's the point of copying this to the tx_extra?
14:42:35 <gingeropolous> sorry, i was thinking about the pool miner payout tx, not the protocol miner reward tx.
14:42:37 <sech1> It is currently part of miner tx
14:42:51 <hyc> where it will only show up if the pool actually mines a block
14:43:04 <sech1> That's what pools do
14:43:50 <hyc> but it only shows up there after the fact.
14:43:57 <hyc> still not seeing how it is used to distribute work
14:44:06 <hyc> yes, extra_nonce is used for that
14:44:29 <hyc> but that is specified in getblocktemplate, so every miner works from a unique template
14:44:30 <sech1> extra_nonce is not directly in the miner's mining blob
14:44:36 <hyc> it doesn't matter what goes into tx_extra
14:44:43 <sech1> but merkle hash of all tx's in the block is there
14:44:52 <sech1> so if you change extra_nonce, you have to update merkle hash
14:45:03 <sech1> this is how different workers get different mining blobs
14:45:42 <sech1> so in theory you could get away without extra_nonce just by shuffling transactions in the block
14:45:58 <sech1> doesn't help when there are not transactions to mine :D
14:46:08 <sech1> *no transactions
14:46:15 <moneromooo> The pools modify hte template afterwards. See reserved_offset.
14:47:01 <moneromooo> They put a 32 bit value there IIRC (at least the zone117x one did).
14:47:05 <sech1> I think it's not used in Monero anymore
14:47:29 <moneromooo> OK, how do they do it now ?
14:47:35 <sech1> getblocktemplate RPC explicitly has extra_nonce parameter
14:49:27 <sech1> https://www.getmonero.org/resources/developer-guides/daemon-rpc.html#get_block_template is a bit misleading
14:49:33 <moneromooo> jtgrassie's pool (which I have the code to here) does it, I just looked.
14:49:35 <sech1> reserve_size is not there anymore IIRC
14:50:39 <moneromooo> Not endian friendly but I guess it actually doesn't matter...
14:51:23 <sech1> nope, reserve_size is still there, just xmrig uses extra_nonce in solo mode
14:53:31 <sech1> anyway, blockhashing_blob doesn't have this extra_nonce or reserved_offset buffer. It only has merkle hash
14:53:40 <hyc> ok I see that now
14:53:52 <sech1> so every time you change blocktemplate_blob by filling in reserved buffer (extra_nonce), you have to update merkle hash
14:55:31 <sech1> and this reserved offset actually points to somewhere inside tx_extra field in miner reward tx
14:58:37 <hyc> so for solo mining you generally don't need it. but e.g. the monerod miner still has options to let you set it
15:49:46 <gingeropolous> so i was thinking about this - this is a coinbase tx. https://monerohash.com/explorer/block/a43412b72f1e0c27935c3fef29d6f419cf42216f7df692fd38f802761aa3c29b
15:49:55 <gingeropolous> this is a pools miner reward tx: https://monerohash.com/explorer/tx/c5abad46f99670b03be22bdf87f7bd211d80e9a915ae2725a1077752e5423d44
15:51:29 <sech1> it's called pool payout
15:52:22 <gingeropolous> ok
16:33:58 <jtgrassie> hyc: correct, there's not a need for reserving space in the miner tx when solo mining
16:34:55 <jtgrassie> it's just pools that need to, so they can create unique jobs from the same set of txs (block template)
16:37:22 <jtgrassie> "extra_nonce", "reserved_size"... same thing different naming. Both just refer to tx_extra data in the miner tx.
17:07:10 <sgp_> for Thorchain and the tx_extra problem, I think it makes most sense to say on the Thorchain blockchain that a certain payment ID is a reference to the desired command strings
17:07:55 <sech1> this just moves data away from Monero blockchain, but the data is still out there somewhere
17:08:24 <sech1> is payment ID encrypted?
17:09:01 <selsta> yes
17:10:25 <sech1> that's better then
17:18:14 <sgp_> <sech1 "this just moves data away from M"> yes, the data for thorchain should be considered porous since they make it all public for verification
17:18:50 <sgp_> we could use the best practice for generating pIDs then in the Monero transactions
17:19:29 <sgp_> there will still be a public record typing specific monero txs to the thorchain deposits, but at least it won't be direct on the monero blockchain nor bloat it
17:43:21 <UkoeHB> Hi all (@ TurtleCoin ); I describe a break in the 'dual-target discrete logarithm problem’, which is a novel hardness assumption defined in the Arcturus paper (see attached). The consequence of this break is that the Arcturus security proof does not hold as written. After discussing with sarang, the author of Arcturus, a proof-of-concept to investigate the consequences of the broken assumption is in
17:43:21 <UkoeHB> progress, and the preprint will either be updated or withdrawn as necessary. https://usercontent.irccloud-cdn.com/file/XHHWF4AD/Break_DualTargetDL.pdf
17:43:51 <sarang> Great catch, UkoeHB!
17:44:09 <sarang> This is the review process working :)
17:44:25 <moneromooo> Nice :)
17:46:20 <sarang> The existing research code was experimental to begin with, but hopefully it goes without saying that the protocol should not be deployed until/unless there's an update identified
17:48:01 <sarang> UkoeHB: cargodog was working on a Rust implementation, FYI: https://github.com/cargodog/arcturus
17:48:14 <sarang> I'll leave it to you to share this with them, if you wish
17:56:29 <sarang> Will work on a proof-of-concept before determining the preprint's fate... IACR prefers not to have preprints withdrawn and then resubmitted with updates
17:58:22 <UkoeHB> github with pdf: https://github.com/UkoeHB/break-dual-target-dl
17:59:18 <TurtleCoin> <iburnmycd> UkoeHB: thanks for the heads up!
18:02:48 <UkoeHB> yep :) I am relieved it is not used in production
18:08:49 <gingeropolous> <sgp_> we could use the best practice for generating pIDs then in the Monero transactions >>> aren't pIDs also on the way out
18:08:51 <gingeropolous> ?
21:18:06 <sarang> Based on my initial proof-of-concept testing, I think that UkoeHB's hardness assumption break implies that Arcturus double spending would be possible with its current protocol
21:18:35 <sarang> I'll continue verifying, but if that is the case, I'll withdraw the preprint with a note about this
21:18:42 <sarang> TurtleCoin: please take note
21:19:17 <sarang> Again, thanks to UkoeHB for answering the question about the novel hardness assumption in Arcuturs!
21:19:19 <sarang> *Arcturus
21:19:33 <selsta> also ping cargodog[m] cargodog[m]1
21:19:35 <moneromooo> What a ruckus
21:19:51 <sarang> UkoeHB already made a note in cargodog[m]'s GitHub repository
21:20:20 <sarang> It may be possible to change the Arcturus protocol to avoid this; but who knows!
21:20:54 <moneromooo> So the protocol is also wrong ? The original claim was that the proof was wrong.
21:21:03 <moneromooo> (I think ^_^)
21:21:53 <sarang> Soundness relied on that hardness assumption, but I wanted to confirm whether or not that _also_ implied problems with the protocol (or just that the assumption needed to be changed)
21:22:40 <sarang> There can be a difference in general between "not provably secure" and "insecure"
21:22:55 <moneromooo> So does "UkoeHB's hardness assumption break implies that Arcturus double spending would be possible" means "if the hardness assumption is false, double spending is possible" or "until the hardness assumption is modified, we must assume double spending might be possible ?
21:23:17 <sarang> I built a proof-of-concept that lets you generate a transaction with an arbitrary key image
21:23:31 <sarang> So a double-spend is possible with the current protocol
21:23:43 <moneromooo> OK, that seems way worse than I thouht then. Thanks.
21:23:46 <sarang> The hardness assumption is false _and_ it means the protocol is insecure
21:24:35 <TurtleCoin> <iburnmycd> Noted. Thanks again for the ping.
21:24:38 <sarang> Yeah, it's too bad that the efficiency gains of Arcturus can't be realized in its current form, but oh well
21:24:44 <moneromooo> Out of cusiosity, is there a repository of assumptions that were thought to be hard and turned out not to be ? :)
21:25:04 <sarang> With its untested assumption it was always unknown if it would work in practice; this is a solid answer to that question
21:25:06 <moneromooo> It looks like this is a thing that might be "found" independently by different people, and a repo of these might help.
21:25:16 <sarang> Ooh, that's a great question
21:25:17 <sarang> I'm not sure
21:25:33 <sarang> I recall reading an analysis of discrete-log-type assumptions a while back, but not broken assumptions
21:26:14 <moneromooo> Anyway, congrats UkoeHB for your find :)
21:26:49 <sarang> In hindsight I feel foolish for not seeing it, but this is why review is useful
21:30:37 <sarang> There's even a conference for cryptographic failures: https://www.cfail.org/
21:30:41 <sarang> I like the idea
21:30:47 <moneromooo> Nice :D
21:30:49 <sarang> Negative results and failed approaches are often unknown
21:30:59 <UkoeHB> cfail lol
21:31:01 <sarang> and that seems like a loss to the scientific/mathematical community
21:31:09 <moneromooo> Hence the drive to have study preregistration.
21:32:45 <sarang> The next deadline is approaching: https://www.cfail.org/call-for-papers
21:32:49 <sarang> I might submit this
21:36:07 <UkoeHB> btw there is no way I would have found this if sarang didn’t state the new assumption very clearly early in the Arcturus paper - it was a very effective and clean way to present it for feedback. A more obscure approach may have increased the risk of this reaching production.
21:36:21 <sarang> Heh, that's overly kind of you UkoeHB !
22:32:09 <sgp_> I know this is sad to find out, but it's obviously very good to know
22:32:32 <sgp_> <sarang "I might submit this"> Please do!
22:32:59 <sarang> Yeah if UkoeHB is cool with a collaborative submission I'm down with it
22:33:16 <sarang> About a week left before deadline
22:33:24 <sarang> Only extended abstract required