<a​remor:matrix.org> I have

<a​remor:matrix.org> Same as anyone that has built Haveno, monero-cpp, or monero-ts from source has. Also the arm build is hosted on getmonero.org

<y​ugao:ifi.uzh.ch> 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<clipped message>

<y​ugao:ifi.uzh.ch> 0.18.3.3/monerod.conf --data-dir ../monero-blockchain/)

<j​ohnsmith1235:matrix.org> 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

.merges

.merge+ 9270 9292

Added

selsta: .4 soon? :P

would like a couple more things included but yes

<n​obfg9000:matrix.org> 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

<p​reland:matrix.org> I must be crazy; I could’ve sworn that the download simply said “Mac” and nothing about architecture only a few days ago 😂

<p​reland:matrix.org> Oh wait

<p​reland:matrix.org> Is there a static build option in the Makefile, or can it only be built natively?

<p​reland:matrix.org> (To answer my question from before, there is no static build option.)

<a​remor:matrix.org> It cannot serve any clients if it is not up to date with the blockchain right? What do you expect the node to perform?

<n​obfg9000:matrix.org> 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.

<a​remor:matrix.org> Sounds like a great idea

<p​reland:matrix.org> 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

<p​reland:matrix.org> 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

<p​reland:matrix.org> 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)

<r​ucknium:monero.social> 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: monero-project/monero #6668#issuecomment-1190894091

<r​ucknium:monero.social> 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.

<n​obfg9000:matrix.org> 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<clipped message>

<n​obfg9000:matrix.org> e else's art, like they just completely forgot how colored coins worked or why they were abandoned

<n​obfg9000:matrix.org> 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<clipped message>

<n​obfg9000:matrix.org> 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<clipped message>

<n​obfg9000:matrix.org> 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

<n​obfg9000:matrix.org> 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

<n​obfg9000:matrix.org> sorry for the rant

n​obfg9000 check out #cuprate

(effort at a rust implementation)

<s​yntheticbird:monero.social> no way cuprate got free ad

<s​yntheticbird:monero.social> lfg

jeffro256: can you try to find out why a commit is missing here? monero-project/monero #9135

<j​effro256:monero.social> that is so weird...

<j​effro256:monero.social> should i squash?

<j​effro256:monero.social> hopefully that'll refresh something and all the changes will show up

jeffro256: can you try to close and open the pull request?

<j​effro256:monero.social> It shows up on the commits page monero-project/monero #9135/commits

<j​effro256:monero.social> And the comments page

<j​effro256:monero.social> Looks like normal now I think

yes, reopening fixed it...must have been a github bug

a bit scary when commits can go missing