Multisig stuff is all out-of-band, right? Anybody working on a way to [privately] [interactively] build a multisig txn on chain?

Doesn't make sense afaict

I've update the protocol using the common dl proof, you can find it here: github.com/h4sh3d/xmr-btc-atomic-sw…lob/dl-proof/whitepaper/xmr-btc.pdf

This would work if Bitcoin's opcode `OP_AND` was not disabled

Maybe we can turn around the protocol and disclose the private key share on the monero side

As I mentioned before this protocol can be implemented between ETH and XMR, with ethereum capabilities

h4sh3d: im convinced u have to disclose the secret key on the monero side. last night i brainstormed a bit in here: demo.codimd.org/QqrMAAIwSNy_L6xMQtJQWQ?both

basically an adaptor signature in monero commits to a public key that locks the swaplock in the btc side

moneromooo: ph4r05 noted that replacing the list of public keys in CLSAG hash inputs with a hash of the lists is better in the event that ring size scales significantly, so I might proactively change this

I don't expect such an increase, but it might reduce the necessary workload in the future if it were to happen

Any particular opinion on this?

It could also be worked into the prehash routine too, committing all keys as part of the signature message

As long as there's some commitment to keys somewhere, it should be fine

Hmm in fact, if the MLSAG prehash routine already includes all public keys and the commitment offset, we could remove the key data from the CLSAG signing routine altogether; it isn't clear if this is already happening

If it is, the key addition to the CLSAG round hashes is redundant!

If it's new code anyway, might as well use the version that's an improvement, even if only slight.

Assuming it's not much more complicated than the one it replaces.

At worst, a single extra two-line device-specific function

really more for future-proofing

Ah yeah the message signed is 'all tx data except the signature itself'. Although it's the key offsets not keys directly

What should be included are the output keys, the commitment keys, and the pseudo-out commitments

which can be used to construct the actual keys that go into the signature

If that's what you mean UkoeHB_

CLSAG only requires the offset keys (one of which is a comm. to zero), but the transaction should include the actual keys used to construct these sets-to-zero

And since you can derive the sets-to-zero from the original keys and pseudo-out commitments, the latter is fine

The message signed by MLSAGS is all data contained in a tx (except the MLSAG themselves). Tx store 'key offsets' which are the block chain indices for all ring members. The one-time addresses for those ring members are not signed

That poses an interesting conundrum about the relationship between offsets and keys

How so?

If the verifier has a different chain view than the prover did, then the offsets need not correspond to the proper keys anyway

It's an offset since indices are stored as relative offsets or each other

No, I get that

But I mean that the verifier is obtaining one-time keys from the offsets and their view of the chain anyway

Well the point of a chain is consensus. If they don't have the same view it's a big problem already right?

Yeah, but I'm trying to think through the consequences of different views when it comes to the signature itself

Since the verifier has to get the keys from the offsets anyway, from its perspective there's a 1-1 correspondence between offsets and keys anyway

and it has no other way (besides signature success) to know if that's the same view the prover had anyway

Sounds right

Meaning that I think this means it is safe to use only the MLSAG prehash message in the CLSAG round hashes, and not the added key lists obtained from the offsets

Since the signature message includes commitments to the offsets for the keys

UkoeHB_: does this seem reasonable to you as well?

e.g. CLSAG round hashes change from `hash(message,list_of_keys,signature_stuff)` to `hash(message,signature_stuff)`

Well I don't really understand what you gain from key prefixing in the first place

It means the prover can't produce signature data and select keys later in an attempt to game the construction

Committing to them assures the verifier that the prover knew the keys it was using in advance

(or could break the hash function, which we assume is not possible)

Well sure they could in your case. Just make a signature ahead of time, then put the keys you want at those indices

Not trivial, not impossible

Right, but in this case the offsets are what are used for the lookups

What would be better is including the keys, so the verifier knows it has the keys that the prover used

but in this case, the offsets are the only things used to obtain the keys in the first place

So "key prefixing" now means "offset prefixing"

Yeah but you could make it look up a future key that hasn't been added to chain yet, then later on fill that index after your signature is done

and the best we can do is assume the prover can't also game the chain structure too much

Then publish the signature in the end

Right, I agree that using only offsets has downsides

but I want to assure that we do the best we can given the way lookups happen

which would be index prefixing

Index prefixing already happens. The question seems to be whether to remove key prefixing

Given that at best, indices and keys always correspond, and at worst, the prover can select a key after the fact (and that the verifier can't detect this anyway as long as lookups happen), there is no advantage to key prefixing in addition to index

^ is what I claim

But only because all verifier lookups happen by index

and therefore, key prefixing adds no additional security

I'm not sure how different that is from non-key prefixing in the normal case. Say you make a signature, no key prefixing. The verifier must learn a public key that makes the sig work, which he presumably learns from you. It would be the same if the signature included an index in its message (i = 1) and then told to find the public key in some table at that index. Which you filled in!

Basically. But the use of an index on the chain at least means that the prover could influence block packing

Well I'm trying to say that index prefixing doesn't really address the purpose of key prefixing, as I understand it

IMO it is an attempt at a partial incomplete solution, given the structure of the chain

Since key prefixing means the key was determined before the signature got made

Better than not including it, but not as ideal as removing index lookups altogether

If the prover can't directly influence block packing, then it's essentially key prefixing

if the prover can influence it enough, then it isn't sufficient

But he certainly can, or can with some probability

Anyone can make tx or mine blocks

Yes, this assumes the probability is low enough compared to the added complexity of having index prefixing

I am _not_ saying that index prefixing is equivalent to key prefixing in general

but I _am_ saying that statistically it's better than doing no prefixing

and since it's computationally trivial, might as well include it

Is there added complexity? It is directly included in the signed message already as the tx blob. More complex to remove it I think!

it = what?

the existing indexing, or the round-hash keys?

Key offsets (indices)

I think I'm being confusing here... I think that because the indexes are already included (and don't really cost much of anything), and because adding round-hash keys doesn't improve security at all, the best solution given the current setup is to remove the round-hash keys and rely instead on the prehash indices

So my proposal is to remove round-hash keys

(which has the added advantage of simplifying things for trezor/ledger, presumably)

Adding round-hash keys doesn't improve severity at all?

No

because they come from the index lookups anyway

they aren't included in the prover's committed transaction data

or rather, not in a way that's separately verified by the verifier

Hmm this goes back to my earlier argument that indices aren't equivalent to keys, since the keys can be set after the sig is done

Well, there are 2 possibilities

1. The prover cannot influence block packing

In this case, the indices and keys are equivalent, security-wise

Right?

Seems that way

2. The prover can influence what public key appears at a given index

In this case, it can select the index, generate the signature, and later pack a malicious public key at that index

Agreed

The verifier will use the index to look up its view of the public key at that index, and include it

It will find the key that the prover maliciously included

Hmm but this discounts that if the prover does this, the inclusion of the key in the round hash at least means that the signature fails both if the index-key combination is invalid (i.e. the block packing failed) or if the prover did not try to set the malicious key beforehand...

I think I get the case you mean here UkoeHB_

An easy fix that's trezor/ledger-friendly is to include a hash of all the pubkeys, then, in the round hash

Meaning they don't need to all be passed to the devices

This is also simpler than modifying mlsag_prehash to a new clsag_prehash

Really depends on whether it's assumed that the prover can influence block packing with high enough probability

It's definitely way higher chance than solving dlp

Oh, for sure

(we hope!)

Doesn't seem like it's worth taking any risks

From my talks with ph4r05, the current ring size means passing the keys directly to the device isn't a problem

but would be for much larger ring sizes

so doing a key hash is future-proofing, if it's needed at all (CLSAG doesn't support large ring sizes well anyway)

If/when the project moves to an epoch-based next-gen protocol, I think it will be important to include both epoch index references and at least truncated hashes of epoch keys

This would also help to mitigate possible shenanigans from malicious remote nodes, since the client could cache epoch hashes and check the keys it receives from its remote node

(assuming that the original sync is valid)

Sounds good to me 😄