<j​0j0xmr:monero.social> Mordinals used tx_extra. So what's the solution?

<3​21bob321:monero.social> Size was restricted

<j​0j0xmr:monero.social> Let me ask in a different way: what would be the ideal solution (not fix) to make sure storing data doesn't affect fungibility?

<g​ingeropolous:monero.social> J0J0XMR: i'm pretty sure there's some discussion on an issue somewhere on github about alternatives, just gotta search

<s​packle_xmr:matrix.org> I have created an alternative Monero testnet (a fork with only the testnet replaced): github.com/spackle-xmr/monero-alt-testnet

<s​packle_xmr:matrix.org> I intend to use it for stress testing with high tx volume (I am doing it this way to avoid disrupting the actual testnet).

<s​packle_xmr:matrix.org> The new testnet is up and running if anyone wants to use it for performance monitoring, or participate.

<s​packle_xmr:matrix.org> My node is at stressnet.net. P2p port is 28085, rpc port is 28090.

<s​packle_xmr:matrix.org> I will begin abusing it on May 1st.

<s​packle_xmr:matrix.org> Any input or feedback is welcome.

<r​brunner7:monero.social> spackle_xmr wrote earlier today:

<r​brunner7:monero.social> > I have created an alternative Monero testnet (a fork with only the testnet replaced): github.com/spackle-xmr/monero-alt-testnet

<r​brunner7:monero.social> That's a bit unfortunate. I tried to tell them a very easy "trick" for a group of people to configure something like a private testnet, or call it "stressnet" in this case.

<r​brunner7:monero.social> But because of that pesky "Can't reach people with Matrix.org homesevers" that still persists for a month or so already I could not contact them to give them the good news

<r​brunner7:monero.social> Thus now they forked Monero which is a bit overkill, and maybe people can't join that "stressnet" easily if they can't compile Monero from source

<r​brunner7:monero.social> So can somebody with a different home server than Monero.social forward them the following:

<r​brunner7:monero.social> spackle_xmr: You don't need a fork of Monero for your "stressnet". Use of a simple Monero startup / command line parameter is all you need. Chekc `--p2p-bind-port`. If all the daemons in your new and temporary network listen on a special port, e.g. 48080, using this parameter, action there won't disturb anybody else.

<r​brunner7:monero.social> Thanks!

<r​brunner7:monero.social> ("Forwarding" simply means posting in this room, as dumb as that may sound. Their Matrix home server will forward what they write. **If* it's not Monero.social, that is.)

<s​packle_xmr:matrix.org> rbrunner7: I read the libera logs, and can see your messages. Thanks for pointing me in a better direction, I'll work on taking that (better) approach.

<r​brunner7:monero.social> Hooray!

<r​brunner7:monero.social> Maybe you can come around to join that boomer playground called "IRC" as well? It looks like the 60's, but things work, dammit.

<s​packle_xmr:matrix.org> I gave IRC a try and I did not find it tempting, but after this hilariously significant oversight/misadventure I suppose it would be negligent not to switch.

<s​packle_xmr:matrix.org> I'll count it as a learning experience.

don't you also have to prevent reseeding? like if you start up without a peerlist, wouldn't monerod try to fetch a list of mainnet peers and connect to them? so you'll need a private testnet peerlist ready before you start?

<r​brunner7:monero.social> Good point. I am not fully sure, but I think the daemon will indeed try to contact the seed nodes of the network you tell it to use, but those won't answer on a port like 48080 of course.

<r​brunner7:monero.social> We probably would have to put up something like a "private seed node" and tell every other daemon its IP, using `--add-priority-node`

<r​brunner7:monero.social> (Another of those startup up / command line parameters)

<s​packle_xmr:matrix.org> hmm, perhaps I was not so far off the mark. I imagine that even when setting a priority node, all it would take is one person connecting to my network with a copy of the existing testnet to force a deep reorg and ruin my sandbox.

<r​brunner7:monero.social> I think to remember that many years back people had such a private testnet running to try a then-brand-new feature called *fluffy blocks*. Not sure about the details, I was not part of that. Maybe @hyc still knows details.

<r​brunner7:monero.social> That peerlist issue could develop into a serious issue, yeah ...

<s​packle_xmr:matrix.org> I am extremely open to suggestions :)

<s​packle_xmr:matrix.org> I deleted the repo, but I can quickly restore it if that ends up being the correct solution.

<j​effro256:monero.social> If you can store data, you can store identifiers, if you can store identifiers, you can affect fungability. The closest thing we could do is the minimize all storage to exactly what is needed to store the "allowed" types of data, and then add in cryptographic proofs that all of these elements were constructed in such a way that it costs exponentially more compute time to encode ea<clipped message>

<j​effro256:monero.social> ch identifying additional bit (i.e. used one-way functions to get this data). We would have to make sure those proofs didn't have their OWN ways to encode arbitrary data (e.g. nonces). All of this is relatively fruitless, however, if the "attackers" don't care about cryptographic security. If they just want to embed the sender's SSN, for example, they "only" have to brute force a <clipped message>

<j​effro256:monero.social> one-way function a billion times to be able to find a preimage for encoding a SSN, even with the strictest of enforcements. The only ideal solution is to use a wallet which doesn't make silly mistakes and screw up your fungability, and have the community attempt to negate any financial incentives to worsen fungability if possible

<j​effro256:monero.social> And anyways, FCMPs mitigate almost all fungability downsides to your peers using tx_extra. The ring signatures were the real problem which caused non-tx_extra users to suffer at the hands of those who did

<j​0j0xmr:monero.social> Thanks for the detailed response.

<c​harutocafe:matrix.org> i have a bitstring with 150 random bits, can anyone guide or provide some assistance on how i can use these to manually make a valid polyseed?

<c​harutocafe:matrix.org> i imagine first i need to convert it to a 176 bit bitstring by adding the feature and birthday bits, then adding the checksum, after that i simply convert those 176 bits word for word in 16 11-bit chunks.

Practically speaking, the easiest way would be to inject the 150 bits as the return value of a custom randbytes function to polyseed and then just call polyseed_create.

<e​ugene_the_dev:matrix.org> Hi, I'm having one issue when using private testnet. I have 10290000000000 piconero unlocked balance in the wallet and when I want to send 980000000000 and 9304000000004 in one transfer I get "not enough money". Despite I leave 5999999996 piconero (which should cover 2 fees) Im keep getting "not enough money"

<e​ugene_the_dev:matrix.org> I checked and I had to leave 100 times the transaction fee to have transaction created. This is my data to rpc wallet

<e​ugene_the_dev:matrix.org> {

<e​ugene_the_dev:matrix.org> "jsonrpc": "2.0",

<e​ugene_the_dev:matrix.org> "id": "0",

<e​ugene_the_dev:matrix.org> "method": "transfer",

<e​ugene_the_dev:matrix.org> "params": {

<e​ugene_the_dev:matrix.org> "destinations": [{'amount': 980000000000, 'address': 'redacted'}, {'amount': 9304000000004, 'address': 'redacted'}],

<e​ugene_the_dev:matrix.org> "account_index": account_index,

<e​ugene_the_dev:matrix.org> "priority": 0,

<e​ugene_the_dev:matrix.org> "ring_size": 0,

<e​ugene_the_dev:matrix.org> "get_tx_key": True,

<e​ugene_the_dev:matrix.org> "do_not_relay": do_not_relay,

<e​ugene_the_dev:matrix.org> "get_tx_hex": True,

<e​ugene_the_dev:matrix.org> "get_tx_metadata": True,

<e​ugene_the_dev:matrix.org> },

<e​ugene_the_dev:matrix.org> }

<e​ugene_the_dev:matrix.org> What might be the issue?

<e​ugene_the_dev:matrix.org> My balance shows

<e​ugene_the_dev:matrix.org> {

<e​ugene_the_dev:matrix.org> "id": "0",

<e​ugene_the_dev:matrix.org> "jsonrpc": "2.0",

<e​ugene_the_dev:matrix.org> "result": {

<e​ugene_the_dev:matrix.org> "balance": 10290000000000,

<e​ugene_the_dev:matrix.org> "blocks_to_unlock": 0,

<e​ugene_the_dev:matrix.org> "multisig_import_needed": false,

<e​ugene_the_dev:matrix.org> "per_subaddress": [{

<e​ugene_the_dev:matrix.org> "account_index": 1,

<e​ugene_the_dev:matrix.org> "address": "redacted",

<e​ugene_the_dev:matrix.org> "address_index": 0,

<e​ugene_the_dev:matrix.org> "balance": 10290000000000,

<e​ugene_the_dev:matrix.org> "blocks_to_unlock": 0,

<e​ugene_the_dev:matrix.org> "label": "somelabel",

<e​ugene_the_dev:matrix.org> "num_unspent_outputs": 3,

<e​ugene_the_dev:matrix.org> "time_to_unlock": 0,

<e​ugene_the_dev:matrix.org> "unlocked_balance": 10290000000000

<e​ugene_the_dev:matrix.org> }],

<e​ugene_the_dev:matrix.org> "time_to_unlock": 0,

<e​ugene_the_dev:matrix.org> "unlocked_balance": 10290000000000

<e​ugene_the_dev:matrix.org> }

<e​ugene_the_dev:matrix.org> }

<e​ugene_the_dev:matrix.org> I'm using 18.3.3

<e​ugene_the_dev:matrix.org> TLDR: I have 10 XMR, I want to send 9.99 (so I leave 0.01 for fee) and I get "not enough money" (despite fee is 0.002).

<r​brunner7:monero.social> No clue. But I have an advice: Debug. Check where in the code it gets to decide that error, and check in a debugger why it thinks the fee is not enough, using a breakpoint and then variable value inspection.

<r​brunner7:monero.social> If you don't know yet how to debug, or have no tool yet: My take it that sooner or later you will need it, so you may start today. I personally use VSCode.

<r​brunner7:monero.social> Oh no, not that problem again: eugene_the_dev is on Matrix.org ... sigh.

<r​brunner7:monero.social> Maybe we put a bounty on solving that problem?

<r​brunner7:monero.social> Of course that's akin to declare defeat in a way, but that problem is sooooo annoying ...

<r​brunner7:monero.social> Or how about a dev strike until the problem is solved? Gotta be creative :)

<d​etherminal:monero.social> there is 3 unspent outputs

<d​etherminal:monero.social> you need to give more fee for it

<s​yntheticbird:monero.social> monero-project/monero #9297 opened an issue regarding building targets in case rust is included into monerod.

<k​ayabanerve:matrix.org> That's not exactly what that issue is, but it's what it should be.

<k​ayabanerve:matrix.org> Also, can someone invite @kayabaNerve:monero.social to this room? I can't :/

<k​ayabanerve:matrix.org> cc plowsof who is an admin here

<1​23bob123:matrix.org> weird you cant invite

<p​lowsof:matrix.org> @kayabaNerve:monero.social: User does not exist

<p​lowsof:matrix.org> invited anyway

<k​ayabanerve:matrix.org> Err, sorry, kayabanerve

<k​ayabanerve:matrix.org> It's all lower case

<k​ayabanerve:monero.social> 👍

<k​ayabanerve:monero.social> Thanks

<s​yntheticbird:monero.social> kayabanervemade some changes accordingly

<k​ayabanerve:monero.social> All platforms we build for are at least tier 2. We generally use the popular tier 2s, which I'd trust, and current proposed uses don't have too much platform specific code.

<s​yntheticbird:monero.social> Maybe I'll say something stupid, but is there a world where monerod will compile through GCC and compile the Rust part with LLVM ? Or is including Rust going to shift monerod to be LLVM mandatory