Is there a document/spec/reference on the p2p protocol used by nodes to talk to eachother? (Other than the code itself)

Some here: github.com/vtnerd/monero/blob/docs_p2p_e2e/docs/LEVIN_PROTOCOL.md

That might be everything ATM, not sure.

Its a part of vtnerd's work on p2p encryption.

hello

What would be needed to have timelocks in Monero? I know this question comes up from time to time, but timelocked transactions (like Bitcoin) would make Haveno more trustless, as it would get us closer to a 2/2 multisig protocol instead of the current 2/3 (where an arbitrator has one of the keys)

A good look at what semantics would be best. A look at whether use of timelocks would introduce too much tx heterogeneity. Someone to do the work (which I do not expect to be hard).

It is possible to emulate bitcoin style timelocks by including a locked input in a tx fwiw.

luigi1111: how available are you in the next days for merges / release?

thanks mooo

with emulate you mean that it basically has the same effect? Meaning a transaction containing a locked input would be relayed after N days or discarded

I mean that my basic understanding of what locking does in bitcoin (prevent a tx from being mined before height N) can be done in monero by including an input locked till N-1 in the tx.

Now, my understanding of bitcoin's locking is vague, there might be subtleties I'm not aware of.

WTF! Zec is overtaking the price of XMR

How is that possible?

Because price by itself means nothing

Also this is not the place for price talk Mohammed Mujahid

he is a bot

Let's make XMR as the future of web 3

he send it into every chat

must be, he was already warned about the off-topic

waterdev[m]: Dude I am huge fan of xmr

I myself own xmr

try to exchange that for some brain cells

I just thought to inform this!

moneromooo: there has been some thought about deprecating monero's current locktime feature ( monero-project/research-lab #78 ). I think bitcoin's NLocktime could be mimicked by adding a `mineable_heights` range rule. I.e. a tx can't be mined except in the heights [a, b].

UkoeHB: that sounds like something fairly trivial to implement. Don't know how that would impact tx uniformity tho

could you pack it into a bulletproof style thing, where hash(mine_height) - hash(current_height) = 0 ? sometimes i think i understand things.

though that wouldn't change a transaction thats been formed at timepoint A only including ringmembmers pre A and then being submitted for inlcusion at timepoint B

selsta: yep

gingeropolous: With seraphis membership proof delegation, you could commit to spending inputs in a certain time range with pedersen commitments, then when it’s time to send the transaction, create membership proofs for your inputs and make range proofs for the timelocks.

The cost for a time lock range [a,b] would then be 2x 32 bytes + 2x range proofs.

I guess the question is whether that method is superior in some way to the Paymo + Sleepy Channels stuff

Has there been any effort to bring tokens to Monero?

Not that I know of. It'd need to be private, which is a tall order.

(I assume you mean like coloured coins)

Hmmm, I just looked up coloured coins. I mean similar to printing cash. You know the source, but from there on it's private.

So, what I'm thinking is that any account can mint their own coin on the Monero network and this coin can be identified by public address that created it. Then if you want to transact with it, you identify which coin you want to send and pay your transaction fees in Monero.

how would that even work

All the Monero privacy methods work regardless of which 'dimension' (token) you're on.

the blockchain isn't made for it

can you clarify to me what you mean with tokens?

cause I thought you did mean tokens as in ethereum tokens

Sounds like how monero works. Coins (outputs) get created, identified by public address, and selected/sent. I might have misunderstood your question, I was assuming you meant coloured coins.

Well, I think of Monero as a special type of token. And I want more of these spcial tokens using the same privacy standards and the ability to mint them w/o being a miner.

So the way I understand Monero is that it's a single-dimension, multi-root DAG, where the nodes are UTXO, edges are transactions, the roots are validation rewards (mining) and the single-dimension is 'Monero.'

In this case, I want to increase the dimensionality

So, more dimensions (tokens) where the roots of the other dimensions are the minting done by the account-source. Does that make sense?

If you mean coloured coins, I see what you want :) Is it what you want, since you said you looked it up ?

If you do, there was talk before, but it never got far, mostly due to the pivacy implications.

(ie, how to hide the colour)

<moneromooo> "(I assume you mean like coloured..." <- we're calling them *coins of colour* now, thanks

<happyjd> "So, what I'm thinking is that..." <- No, this is not ho fungibility works. Color coins on XMR are taking a fungible asset (monero) and coloring it, rendering it non-fungible, which means it can be differentiated from others.

s/ho/how/

This is why you don't see XMR color coins or XMR shit tokens, it requires the property of being not fungible, which is the antithesis to what monero is, which is fungible coins.

Yes, it would give the ability to create XMR shit tokens.

I see your point. I'm new here so correct me if I'm wrong: XMR is already non-fungible with other tokens, and this isn't the fungibility we're looking for (isn't what's important is that Monero is fungible with other Monero?). So, adding more dimensions would allow for people to use the monero mainnet and pay with transaction fees in Monero.

<happyjd> "So, what I'm thinking is that..." <- I also thought about a protocol similar to colored coins but less complicated. You would essentially publish the view key to a wallet and a genesis transaction where the token is configured. I especially think this could be helpful to create something similar to the ethereum name system. Sending a transaction with a certain amount to the address with the published viewkey and a tx_extra of

{domain: "mydomain.monero", onion: "sdkjfjksdfhjkskjdf.onion"} would give the one who can do get_tx_proof for this transaction the power to switch the onion link it directs to and offer the domain for sale (so that a different tx id gets this power, after showing a certain amount was sent to a specified address) If we have a browser wallet (which I am working on right now lol) we can conveniently do name resolution in the browser.. and

if people use brave the onion links should also be a given. We can also use these names for usage as usernames in forum like systems that we can build where people can login with one click by using get_tx_proof. we can also use these names for other tokens so the tokens are properly named and do not collide.

"XMR is already non-fungible with other tokens, and this isn't the fungibility we're looking for" <-- oh, do you mean just forking monero ?

happyjd: My basic objection to this kind of idea is it would reduce the upper limit of tx throughput for plain Monero transactions, since now all your normal Monero nodes have to handle verifying/storing the other stuff.

Ok, let me give more background. I'm working on creating cryptocurrencies where communities can control the monetary system (ability to to mint).

I was thinking of having microservices where I host Monero for these communities (since XMR is awesome and closest thing to digital cash). However, this would not scale in a decentralized fashion (since only I and the communities would service this).

<happyjd> "I see your point. I'm new here..." <- yes.

* yes. you could completely stay in monero.

<moneromooo> ""XMR is already non-fungible..." <- I think the thing he is talking about that he cant easily use monero to pay for ethereum gas fees to host an NFT

* talking about is, that he

Yes!^ you're paying for the Ethereum mainnet. So, I'd like to create a system where people pay for the Monero mainnet.

I'm not looking for it to be as flexible as Ethereum. Many copies of Monero would work just fine.

I'm confuseder now that a minute ago now :D

I do agree with UkoeHB. It would increase the load. But this is due to XMR being more popular, which is good right?

UkoeHB was saying that monerod would have extra work to do for a given tx, to verify your consensus rules to allow tokens.

happyjd: I think the thing I have in mind would solve your problem

I'm all ears!

<spirobel[m]> "I also thought about a protocol..." <- this could be used for any kind of token. The naming system was just an example. Its just a special case of a token.

In your case, it would be printing 1 token in that particular dimension, rather than many. Am I right?

but I understand that my effort post might not be enough....I am currently working on some precursory steps that need to be done: get the browserwallet of the ground and convince people it makes sense.

happyjd: no. you anyone can create new tokens. Just publish the viewkey and a genesis transaction.

*the viewkey to one wallet

s/you//

s/of/off/

I made a post on Reddit, it's waiting for Mod input - reddit.com/r/Monero/comments/r1a5f7…been_any_effort_on_adding_tokens_to

This might explain more.

<moneromooo> "UkoeHB was saying that monerod..." <- there wouldnt be extra work. the verification of these colored coins style tokens is completely on the side of the wallet

Are you just using the monero network for storage?

"Are you just using the monero network for storage?" - No

"monerod would have extra work to do for a given tx," - yes.

It would check jump to the other token's dimension and then everything else is the same.

s/check//

spirobel[m], correct me if I'm wrong but you're looking for NFT capabilities? I'm not sure how that would work given Monero is so focused on fungibility.

I'm looking to create more Monero-like (fungible) tokens.

happyjd: my concept is different from this. the same qualities that apply to colored coins apply to it. If you read for example the introduction on the simple ledger protocol over at bitcoin cash. it gives a good breakdown. slp.dev/specs/slp-token-type-1/#use-cases " 4. Non-invasive. It should require no changes to the underlying Bitcoin Cash protocol." so there is no changes to monerod or more work.

happyjd: please just read what I wrote. Also NFT is just a special kind of token. the concept I have in mind works for: a naming system, nfts and other tokens.

image.png

It is possible to get NFTs on a monero like chain, by adding a balance based system to the chain, and trustless switch of money between the balance based system and the output based system.

You don't get private sending of tokens, but the trustless switch means that actual sender and recipients are still protected by monero privacy.

And you can create your own tokens/NFTs at will.

It does require heavy changes to monero though (read, changes that'll never fly in monero itself).

you could also send that information over tx_extras on the actual monero chain in theory

and by using a sub chain

moneromooo: I think it doesnt. It could be done with just tx_extra

If the daemon does not have to verify your token transactions are valid, you're right.

spirobel[m]: I think you would need tx_extra, and another decentralized chain or IPFS to store stuff on

moneromooo: yes. this would be done in the wallet.

also: if people dont want to participate and still use other wallets there is no problem

spirobel[m]: you would need a signing system in the wallet though

waterdev[m]: that is already there getmonero.org/resources/developer-guides/wallet-rpc.html#get_tx_proof

nothing is stopping us from building this right now.

but building these wallets for multiple platforms would be a bit of a challenge, cause multiple codebases for different platforms

waterdev[m]: no. This needs to be a browserwallet anyhow so the code is platform independent anyway especially because we will use monero-javascript which compiles the daemon with emscripten to js. so nothing touches the bare metal.

spirobel[m]: as it will be local, it could then be compiled thanks to electrum

waterdev[m]: I think standalone wallets are a path in the wrong direction. Browser wallets are the future. metamask is used by more than 10 million users per month. But you are right. If someone wanted to he could use electron.

spirobel[m]: isn't it local only anyways? (by that I mean no viewing or private keys shared with a server)

browser wallets have pretty much zero on-device security

hyc: not if its a local wallet