00:23:26 <merope> Is there a document/spec/reference on the p2p protocol used by nodes to talk to eachother? (Other than the code itself)
00:25:41 <sethsimmons> Some here: https://github.com/vtnerd/monero/blob/docs_p2p_e2e/docs/LEVIN_PROTOCOL.md
00:26:03 <sethsimmons> That might be everything ATM, not sure.
00:26:04 <sethsimmons> Its a part of vtnerd's work on p2p encryption.
09:51:51 <Joun> hello
11:31:48 <ErCiccione> 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)
11:35:12 <moneromooo> 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).
11:35:51 <moneromooo> It is possible to emulate bitcoin style timelocks by including a locked input in a tx fwiw.
11:40:27 <selsta> luigi1111: how available are you in the next days for merges / release?
11:48:35 <ErCiccione> thanks mooo
11:49:46 <ErCiccione> 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
12:01:58 <moneromooo> 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.
12:02:20 <moneromooo> Now, my understanding of bitcoin's locking is vague, there might be subtleties I'm not aware of.
13:24:43 <MohammedMujahid[> WTF! Zec is overtaking the price of XMR
13:24:43 <MohammedMujahid[> How is that possible?
13:27:12 <merope> Because price by itself means nothing 
13:27:35 <merope> Also this is not the place for price talk Mohammed Mujahid 
13:28:00 <waterdev[m]> he is a bot
13:28:02 <MohammedMujahid[> Let's make XMR as the future of web 3 
13:28:11 <waterdev[m]> he send it into every chat
13:28:26 <dont_thread_on_m> must be, he was already warned about the off-topic
13:28:48 <MohammedMujahid[> waterdev[m]: Dude I am huge fan of xmr 
13:29:01 <MohammedMujahid[> I myself own xmr 
13:29:32 <dont_thread_on_m> try to exchange that for some brain cells
13:29:33 <MohammedMujahid[> I just thought to inform this! 
14:47:19 <UkoeHB> moneromooo: there has been some thought about deprecating monero's current locktime feature ( https://github.com/monero-project/research-lab/issues/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].
14:59:41 <ErCiccione> UkoeHB: that sounds like something fairly trivial to implement. Don't know how that would impact tx uniformity tho
15:51:33 <gingeropolous> could you pack it into a bulletproof style thing, where hash(mine_height) - hash(current_height) = 0 ?  sometimes i think i understand things.
15:52:09 <gingeropolous> 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
16:26:57 <luigi1111> selsta: yep
16:41:59 <UkoeHB> 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.
16:42:37 <UkoeHB> The cost for a time lock range [a,b] would then be 2x 32 bytes + 2x range proofs.
16:49:45 <carrington[m]> I guess the question is whether that method is superior in some way to the Paymo + Sleepy Channels stuff
17:21:56 <happyjd> Has there been any effort to bring tokens to Monero?
17:22:36 <moneromooo> Not that I know of. It'd need to be private, which is a tall order.
17:22:54 <moneromooo> (I assume you mean like coloured coins)
17:24:49 <happyjd> Hmmm, I just looked up coloured coins. I mean similar to printing cash. You know the source, but from there on it's private.
17:27:37 <happyjd> 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.
17:27:45 <waterdev[m]> how would that even work
17:28:15 <happyjd> All the Monero privacy methods work regardless of which 'dimension' (token) you're on.
17:28:33 <waterdev[m]> the blockchain isn't made for it
17:29:52 <waterdev[m]> can you clarify to me what you mean with tokens?
17:30:23 <waterdev[m]> cause I thought you did mean tokens as in ethereum tokens
17:31:40 <moneromooo> 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.
17:32:50 <happyjd> 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.
17:33:18 <happyjd> 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.'
17:33:29 <happyjd> In this case, I want to increase the dimensionality
17:34:37 <happyjd> So, more dimensions (tokens) where the roots of the other dimensions are the minting done by the account-source. Does that make sense?
17:35:16 <moneromooo> If you mean coloured coins, I see what you want :) Is it what you want, since you said you looked it up ?
17:35:45 <moneromooo> If you do, there was talk before, but it never got far, mostly due to the pivacy implications.
17:35:56 <moneromooo> (ie, how to hide the colour)
17:37:49 <rock[m]> <moneromooo> "(I assume you mean like coloured..." <- we're calling them *coins of colour* now, thanks
17:38:39 <rock[m]> <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.
17:38:44 <rock[m]> s/ho/how/
17:39:19 <rock[m]> 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.
17:44:02 <happyjd> Yes, it would give the ability to create XMR shit tokens.
17:44:03 <happyjd> 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.
17:45:22 <spirobel[m]> <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
17:45:22 <spirobel[m]> {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
17:45:22 <spirobel[m]> 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. 
17:46:11 <moneromooo> "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 ?
17:47:21 <UkoeHB> 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.
17:49:22 <happyjd> Ok, let me give more background. I'm working on creating cryptocurrencies where communities can control the monetary system (ability to to mint).
17:49:22 <happyjd> 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).
17:50:07 <spirobel[m]> <happyjd> "I see your point. I'm new here..." <- yes.
17:50:28 <spirobel[m]> * yes. you could completely stay in monero.
17:51:12 <spirobel[m]> <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
17:51:48 <spirobel[m]> * talking about is, that he
17:52:20 <happyjd> Yes!^ you're paying for the Ethereum mainnet. So, I'd like to create a system where people pay for the Monero mainnet.
17:52:21 <happyjd> I'm not looking for it to be as flexible as Ethereum. Many copies of Monero would work just fine.
17:52:46 <moneromooo> I'm confuseder now that a minute ago now :D
17:52:49 <happyjd> I do agree with UkoeHB. It would increase the load. But this is due to XMR being more popular, which is good right?
17:53:54 <moneromooo> UkoeHB was saying that monerod would have extra work to do for a given tx, to verify your consensus rules to allow tokens.
17:54:15 <spirobel[m]> happyjd: I think the thing I have in mind would solve your problem
17:54:50 <happyjd> I'm all ears!
17:54:56 <spirobel[m]> <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. 
17:56:26 <happyjd> In your case, it would be printing 1 token in that particular dimension, rather than many. Am I right?
17:57:01 <spirobel[m]> 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.
17:57:43 <spirobel[m]> happyjd: no. you anyone can create new tokens. Just publish the viewkey and a genesis transaction.
17:57:56 <spirobel[m]> *the viewkey to one wallet
17:58:16 <spirobel[m]> s/you//
17:58:54 <spirobel[m]> s/of/off/
18:00:42 <happyjd> I made a post on Reddit, it's waiting for Mod input - https://www.reddit.com/r/Monero/comments/r1a5f7/has_there_been_any_effort_on_adding_tokens_to/
18:00:42 <happyjd> This might explain more.
18:01:38 <spirobel[m]> <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
18:03:24 <UkoeHB> Are you just using the monero network for storage?
18:04:11 <happyjd> "Are you just using the monero network for storage?" - No
18:04:48 <happyjd> "monerod would have extra work to do for a given tx," - yes.
18:05:16 <happyjd> It would check jump to the other token's dimension and then everything else is the same.
18:05:30 <happyjd> s/check//
18:07:26 <happyjd> 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.
18:07:27 <happyjd> I'm looking to create more Monero-like (fungible) tokens.
18:08:59 <spirobel[m]> 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. https://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.
18:10:06 <spirobel[m]> 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.
18:10:30 * rock[m] uploaded an image: (5KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/QKtRrJPlARoyVBcgwkcesSkw/image.png >
18:10:38 <waterdev[m]> image.png
18:11:54 <moneromooo> 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.
18:12:32 <moneromooo> You don't get private sending of tokens, but the trustless switch means that actual sender and recipients are still protected by monero privacy.
18:13:03 <moneromooo> And you can create your own tokens/NFTs at will.
18:13:39 <moneromooo> It does require heavy changes to monero though (read, changes that'll never fly in monero itself).
18:13:40 <waterdev[m]> you could also send that information over tx_extras on the actual monero chain in theory
18:13:56 <waterdev[m]> and by using a sub chain
18:14:04 <spirobel[m]> moneromooo: I think it doesnt. It could be done with just tx_extra
18:14:34 <moneromooo> If the daemon does not have to verify your token transactions are valid, you're right.
18:14:43 <waterdev[m]> spirobel[m]: I think you would need tx_extra, and another decentralized chain or IPFS to store stuff on
18:15:18 <spirobel[m]> moneromooo: yes. this would be done in the wallet. 
18:15:56 <spirobel[m]> also: if people dont want to participate and still use other wallets there is no problem
18:16:12 <waterdev[m]> spirobel[m]: you would need a signing system in the wallet though
18:16:50 <spirobel[m]> waterdev[m]: that is already there https://www.getmonero.org/resources/developer-guides/wallet-rpc.html#get_tx_proof
18:17:23 <spirobel[m]> nothing is stopping us from building this right now.
18:18:36 <waterdev[m]> but building these wallets for multiple platforms would be a bit of a challenge, cause multiple codebases for different platforms
18:22:09 <spirobel[m]> 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. 
18:23:25 <waterdev[m]> spirobel[m]: as it will be local, it could then be compiled thanks to electrum
18:25:41 <spirobel[m]> 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. 
18:26:32 <waterdev[m]> spirobel[m]: isn't it local only anyways? (by that I mean no viewing or private keys shared with a server)
22:53:02 <hyc> browser wallets have pretty much zero on-device security
22:53:43 <waterdev[m]> hyc: not if its a local wallet