06:31:17 I have 06:33:03 Same as anyone that has built Haveno, monero-cpp, or monero-ts from source has. Also the arm build is hosted on getmonero.org 09:40:44 hello, I am running a monero node (without block sync), and I set up the conf file, and made my node a public node, but every time my node just doesn’t have incoming, I also checked the firewall, port 18080 is open. Can anybody help me with what should I do to have incoming links? (./monerod --no-sync --config-file=/Users/gayu/Documents/monero_node/monero-x86_64-apple-darwin11-v 09:40:44 0.18.3.3/monerod.conf --data-dir ../monero-blockchain/) 10:15:39 Hello everyone, when I was checking xmr rpc, I found that some transaction destinations have display addresse and some transaction destinations are empty. This is why 12:44:36 .merges 12:44:36 -xmr-pr- 8396 8488 9064 9149 9194 9199 9200 9202 9204 9205 9211 9232 9245 9252 9254 9257 9259 9260 9267 9268 9282 9291 12:45:00 .merge+ 9270 9292 12:45:00 Added 12:51:12 selsta: .4 soon? :P 12:51:43 would like a couple more things included but yes 13:34:39 well idk that much about crypto, but I thought of this one implementation. Lets say you have a public signing key, you can prove it's not arbitrary data by having the key sign itself. Then it would be limited to just how much data you can get in through vanity mining 13:43:07 I must be crazy; I could’ve sworn that the download simply said “Mac” and nothing about architecture only a few days ago 😂 13:43:26 Oh wait 13:43:45 Is there a static build option in the Makefile, or can it only be built natively? 13:48:45 (To answer my question from before, there is no static build option.) 13:52:40 It cannot serve any clients if it is not up to date with the blockchain right? What do you expect the node to perform? 14:10:48 yeah this is what I mean, I think its the way to go as long as you can produce these proofs without much overhead. If you can write arbitrary data to the blockchain it encourages wasteful non-transaction use cases, which hurt tansaction rate in the long run. Also it allows miners to activate soft forks themselves. 14:34:50 Sounds like a great idea 14:43:35 Using some Rust-esqe (not actually Rust code before someone starts a flame war) strong typing on the block data should more-or less fix that issue 14:44:52 IE the only data that can be added to a block must be directly related to the transaction itself; and most (if not all) of the raw data is outside the control of any one party 14:46:39 Even then it wouldn’t be perfect (ie interested parties could still mint blocks with specific desired properties so long as the block is still valid; think running a node that will only mine a block at a given time for example) 15:02:02 preland: I think it has been said many times that this is not possible with the current state of cryptography. The creator of transactions can choose, at will, much of the data that composes cryptographic signatures. If they didn't have this freedom, probably someone could guess the private keys AFAIK: https://github.com/monero-project/monero/issues/6668#issuecomment-1190894091 15:03:18 Townforge already has a practical implementation of packing message data into Monero's signatures so that tx recipients can get a message. No one else knows that the tx is not actually a normal tx that just sends coins. 18:10:58 it's such a shame that there are agents like mordinals that want to upload arbitrary data to the blockchain in the first place. AFAIK old-school "colored coins" never required adding metadata to the chain, but when this same idea was re-introduced as "NFTs" people started thinking that it had to be like a picture of a monkey or something, or that you could make money off of someon 18:10:58 e else's art, like they just completely forgot how colored coins worked or why they were abandoned 18:25:42 I actually had an idea for colored coins on monero called "colored cohorts" which would have sort of a semi-fungibility wherein you only mix the "colored enotes" amoungst each other (the "cohort"). For example, you could issue "colored enotes" that repesent like a ticket for an event, and they would be fungible amoungst themselves. To implement it you would need a special transact 18:25:42 ion proof that shows that the amount of one of the inputs is equal to the fees for the transaction (this input would not be "colored", so you can use normal monero to move the "colored enotes" around)... and also metadata so that normal transactions won't use your transaction for decoys. But the point is that you would have an "NFT" system that shows off privacy tech and you would 18:25:43 just distribute whatever meta-data associated with the "colored enote" out of band with a signature from the creator so it doesn't involve spamming the chain with big files (which you should just use IPFS/Bittorrent for if your "colored enotes" are like some pointer to digial art). dunno how this would work with FCMPs tho 18:30:57 on an unrelated note, i think having an alternate implementation of monero (maybe in another language like Ada or rust) would be cool in the long term just to ensure better resistance of the network against side-channels 18:31:07 sorry for the rant 18:49:29 n​obfg9000 check out #cuprate 18:49:45 (effort at a rust implementation) 19:22:41 no way cuprate got free ad 19:22:46 lfg 19:28:51 jeffro256: can you try to find out why a commit is missing here? https://github.com/monero-project/monero/pull/9135 22:43:24 that is so weird... 22:43:53 should i squash? 22:44:19 hopefully that'll refresh something and all the changes will show up 22:52:38 jeffro256: can you try to close and open the pull request? 22:56:43 It shows up on the commits page https://github.com/monero-project/monero/pull/9135/commits 22:56:56 And the comments page 22:57:08 Looks like normal now I think 22:57:15 yes, reopening fixed it...must have been a github bug 22:57:32 a bit scary when commits can go missing