sarang: Thorchain is expecting to use multisig. They modified the Monero wallet to include parallel generation gitlab.com/thorchain/tss/monero-sign

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

sgp_: Is this referring to the Triptych research sarang is conducting?

dEBRUYNE: yeah

looks like Thorchain is doing some pretty interesting things, but also that it could have inadvertent effects on the network. Some initial context first:

They modified the Monero wallet to add additional RPC commands for multisig wallets. You can see that here: gitlab.com/thorchain/tss/monero-sign

Then, they are hoping to require users to send transactions to Thorchain using a long tx_extra string

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

I will keep trying to come up with something else that works for them

Is this a bullshit use or an actual interesting use of extra ?

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

But what do they want to do ? :)

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

tx_extra would look like ADD:XMR.XMR:<thorchain_address>

How much data in the intent ?

ADD:XMR.XMR:thor1krcz33mejvc5f6grj2c5w5x3kuj7mnjhgqltj8

ADD:XMR:thor1krcz33mejvc5f6grj2c5w5x3kuj7mnjhgqltj8

examples would be the two above

Encrypted or plaintext?

plaintext probably

Are ADD and XMR placeholders ? If so, 3 chars each ?

oof

the format they use is `ADD:XMR:XMR`, but since XMR is the base asset, they are open to shortening it to `ADD:XMR`

for adding BTC liquidity it would look like `ADD:BTC:<thorchain_address>`

except Bitcoin can't store that much info either

One can plonk encrypted 32 bytes in a BP+. 8 bytes in an encrypted pid.

The "thorchain_address" is 32 bytes I assume ?

I'm confirming

(there's no tooling atm for BP embedding, but I'd want to do that anyway)

the address string looks longer than 32 bytes no? thor1krcz33mejvc5f6grj2c5w5x3kuj7mnjhgqltj8

43 bytes? 39 without the `thor`?

Decoded, obviously.

Like monero addresses are 64 bytes but the user address is like 98 chars or whatever.

keys.

ah, I'm too dumb to know this stuff

there are 2 main commands: `ADD` and `SWAP`

`SWAP` would look like `SWAP:CHAIN.ASSET:DESTINATION:LIMIT:AFFILIATE:FEE`

so there's quite a bit of text there

eg: `SWAP:THOR.RUNE:tthor1zpa4c6zpa4cyz9s93xuje2pwkswsqzn2zpa4c:3141441780:tthor1ql2tcqyrqsgnql2tcqyj2n8kfdmt9lh0yzql2tcqy:10`

transactions are so cheap you just send a dozen

they definitely can send this data with tx_extra, but obviously I would like a way around that

and they don't really want to complicate everything on their end where possible

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.

Kinda sad about it though.

fwiw, they will leak all info anyway with the receiving monero wallet, which will publicly share view keys and key images

Oh, evil bastards...

leaving aside tx_extra for now, let's talk about multisig

this is where an expert will need to review what they have done

they modified the C++ code to add new RPC commands gitlab.com/thorchain/tss/monero-sign

sign_multisig_parallel, export_sigkeys, accumulate_multisig, check_transaction, save_pool_wallet

who would know how to look at this? rbrunner ? vtnerd ?

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

Yeah that's my understanding - they are using a more parallel approach

the concept is legit, idk about their implementatin

Is this something we should try to add to the main codebase

Someone would need to review theirs

ugh I can't even comment here, this is annoying af monero-project/monero #6668

ugh tx_extra. sgp_ , pastebin what you wanted to post on the thread and i or someone can copypasta

Yes multisig needs several updates monero-project/research-lab #67

gingeropolous: paste.mozilla.org/LXSOF9RG

done: monero-project/monero #6668

are tx extra not encrypted at all?

correct

its just cleartext, anything goes

and max length is 255 bytes, interesting. I need to spam some stuff for eternity before too late :)

sech1, i think the max length was enforced due to deadbeef xmrchain.net/tx/fba62a80ff850216712…809973bae29b2b93479c433d4d3ab99ec48

mining pools use tx_extra to distribute work between miners

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)

i think we can hack it such that coinbase can still use tx_extra , would address mining pool issue

wait what? how do mining pools distributed work with tx_extra?

i think sech1 meant payments

they're not generating txs except on payouts?

extra_nonce field

You can't just have 10,000 miners using the same 32-bit nonce space

this is the first I'm hearing of mining pools using this

every connected woker gets their unique extra_nonce

<sgp_ "this is the first I'm hearing of"> you mean pools using extra_nonce?

Been there since bitcoin

All pools use this, ask Snipa or M5M400

it's on me that I didn't know, but I am just now learning yeah

Can't have it any other way, since you only have 4 billion nonces before having to switch to a new block template

extra_nonce is in block header, not per-txn

??

extra_nonce is a part of tx_extra in miner reward tx

You could regen the ouput per miner :)

this is how I can fingerprint mining pools and even solo miners

The xmrig-proxy splits the nonce range using the top 8 bits on the other hand, right?

yes

it creates new connection to the pool per each 256 workers

NiceHash does the same

<sech1> extra_nonce is a part of tx_extra in miner reward tx >> hrm, and the miner reward tx is NOT the coinbase huh.

??

it is coinbase

How do you know ? Is monero anon so bad you can tell ?

and line 87 there

still not getting it. extra_nonce is an input to getblocktemplate

that's not per-tx

so what's the point of copying this to the tx_extra?

sorry, i was thinking about the pool miner payout tx, not the protocol miner reward tx.

It is currently part of miner tx

where it will only show up if the pool actually mines a block

That's what pools do

but it only shows up there after the fact.

still not seeing how it is used to distribute work

yes, extra_nonce is used for that

but that is specified in getblocktemplate, so every miner works from a unique template

extra_nonce is not directly in the miner's mining blob

it doesn't matter what goes into tx_extra

but merkle hash of all tx's in the block is there

so if you change extra_nonce, you have to update merkle hash

this is how different workers get different mining blobs

so in theory you could get away without extra_nonce just by shuffling transactions in the block

doesn't help when there are not transactions to mine :D

*no transactions

The pools modify hte template afterwards. See reserved_offset.

They put a 32 bit value there IIRC (at least the zone117x one did).

I think it's not used in Monero anymore

OK, how do they do it now ?

getblocktemplate RPC explicitly has extra_nonce parameter

getmonero.org/resources/developer-g…/daemon-rpc.html#get_block_template is a bit misleading

jtgrassie's pool (which I have the code to here) does it, I just looked.

reserve_size is not there anymore IIRC

Not endian friendly but I guess it actually doesn't matter...

nope, reserve_size is still there, just xmrig uses extra_nonce in solo mode

anyway, blockhashing_blob doesn't have this extra_nonce or reserved_offset buffer. It only has merkle hash

ok I see that now

so every time you change blocktemplate_blob by filling in reserved buffer (extra_nonce), you have to update merkle hash

and this reserved offset actually points to somewhere inside tx_extra field in miner reward tx

so for solo mining you generally don't need it. but e.g. the monerod miner still has options to let you set it

so i was thinking about this - this is a coinbase tx. monerohash.com/explorer/block/a4341…419cf42216f7df692fd38f802761aa3c29b

this is a pools miner reward tx: monerohash.com/explorer/tx/c5abad46…d211d80e9a915ae2725a1077752e5423d44

it's called pool payout

ok

hyc: correct, there's not a need for reserving space in the miner tx when solo mining

it's just pools that need to, so they can create unique jobs from the same set of txs (block template)

"extra_nonce", "reserved_size"... same thing different naming. Both just refer to tx_extra data in the miner tx.

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

this just moves data away from Monero blockchain, but the data is still out there somewhere

is payment ID encrypted?

yes

that's better then

<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

we could use the best practice for generating pIDs then in the Monero transactions

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

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

progress, and the preprint will either be updated or withdrawn as necessary. usercontent.irccloud-cdn.com/file/XHHWF4AD/Break_DualTargetDL.pdf

Great catch, UkoeHB!

This is the review process working :)

Nice :)

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

UkoeHB: cargodog was working on a Rust implementation, FYI: github.com/cargodog/arcturus

I'll leave it to you to share this with them, if you wish

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

github with pdf: github.com/UkoeHB/break-dual-target-dl

<iburnmycd> UkoeHB: thanks for the heads up!

yep :) I am relieved it is not used in production

<sgp_> we could use the best practice for generating pIDs then in the Monero transactions >>> aren't pIDs also on the way out

?

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

I'll continue verifying, but if that is the case, I'll withdraw the preprint with a note about this

TurtleCoin: please take note

Again, thanks to UkoeHB for answering the question about the novel hardness assumption in Arcuturs!

*Arcturus

also ping cargodog[m] cargodog[m]1

What a ruckus

UkoeHB already made a note in cargodog[m]'s GitHub repository

It may be possible to change the Arcturus protocol to avoid this; but who knows!

So the protocol is also wrong ? The original claim was that the proof was wrong.

(I think ^_^)

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)

There can be a difference in general between "not provably secure" and "insecure"

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 ?

I built a proof-of-concept that lets you generate a transaction with an arbitrary key image

So a double-spend is possible with the current protocol

OK, that seems way worse than I thouht then. Thanks.

The hardness assumption is false _and_ it means the protocol is insecure

<iburnmycd> Noted. Thanks again for the ping.

Yeah, it's too bad that the efficiency gains of Arcturus can't be realized in its current form, but oh well

Out of cusiosity, is there a repository of assumptions that were thought to be hard and turned out not to be ? :)

With its untested assumption it was always unknown if it would work in practice; this is a solid answer to that question

It looks like this is a thing that might be "found" independently by different people, and a repo of these might help.

Ooh, that's a great question

I'm not sure

I recall reading an analysis of discrete-log-type assumptions a while back, but not broken assumptions

Anyway, congrats UkoeHB for your find :)

In hindsight I feel foolish for not seeing it, but this is why review is useful

There's even a conference for cryptographic failures: cfail.org

I like the idea

Nice :D

Negative results and failed approaches are often unknown

cfail lol

and that seems like a loss to the scientific/mathematical community

Hence the drive to have study preregistration.

The next deadline is approaching: cfail.org/call-for-papers

I might submit this

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.

Heh, that's overly kind of you UkoeHB !

I know this is sad to find out, but it's obviously very good to know

<sarang "I might submit this"> Please do!

Yeah if UkoeHB is cool with a collaborative submission I'm down with it

About a week left before deadline

Only extended abstract required