Hi guys, anyone build succeed in solaris?

There were errors about in6addr_any undeclared issues

Does anyone meet this before?

can a monero transaction co-exist in mempool and blocks with same tx_hash?

nandubatchu: In src/cryptonote_core/cryptonote_core.cpp in core::add_new_tx, the transaction is not actually added to the mempool if the mempool or blockchain already has it, so I guess not

BLOCK ADDED AS ALTERNATIVE ON HEIGHT: what does this mean?

netsplit?

feels like the 90s again

I am seeing two transfers inside a wallet one of type "in" and other of type "pool" with the same tx_hash.

Is this an expected behaviour?

Where do I post this question?

here, but you may want to stick around a little for a good answer :)

anyone have some xmrs to give me?

i'm in stagenet, all faucets seems to be not working

maxwilliamson, community.xmr.to/faucet/testnet

says "Sorry you are blocked."

also you can easily mine it with the node solo mode

use tor ? or a vpn ?

give me your stagenet address

nah, normal conn

address

It used to build pm Solaris. Patches welcome if it doesn't anymore.

53rrTSdMTD8a84afiUuc79GUGTXH3kaaGgJiAAnT5SbFdBEenToJjSg2KBmPB8nZPC9qXXCZoLnPLZzAujyB5RNoFUvaEiU

stagenet ?

hmm faucet seems not to be working tho ...

yeah stagenet

you runing a node ?

yep

just set mining on wait a while

maxwilliamson: I can send you also stagenet coins?

i_a_ would appreciate that

ok just a second

tomsmeding: any lead to ask this question to?

moneromooo: any help on my issue?

Ah, I missed it. Fixed in git.

maxwilliamson: txid 1583fb874c8a52de70c15e47155a759a57607354e054e31e777ce1f2095d51bf (still in a pool)

And on master: 27457a2

checked, thx man you're a lifesaver.

moneromooo: actually all the incoming transfers are duplicated with type="pool".

Evem with the patch ?

moneromooo: which patch?

The one I just pointed you to above.

stupid question: i have a couple transactions in mempool on my node. some 4 hours old. they show as relayed: true but are not mined. what are the possible reasons?

also I can't find them neither on xmrchain nor on node.supportxmr.com

can I re-relay the TX?

I have nothing in my txpool older than 2 minutes

Could be they're invalid. Could be you had a network hiccup at the time, and they did not get re-relayed yet.

Could be you're connected to only evil nodes that drop your data.

Could be you're lying, or can't read. Could be I'm misreading your stuff. Or some MITM changed your line in flight. Or I'm imagining all of this...

moneromooo: well, I'm not lying, so we can rule that out. trust me :P

all I know is I have 29 pool payments jacked up in mempool, monerod is happily syncing and the tx are marked as relayed.

It's your own txes then ?

Greating a completely useless error attempting to re-relay them. I'm going to pull the monerod logs in a sec.

Did you double spend them from another daemon right after ?

Oh, if you set_log +*txpool*:DEBUG then start_mining then stop_mining, it'll tell you why it doesn't add them.

You just have to create one template, you can stop mining right after that.

It might not be super helpful though.

2019-12-17 17:51:05.896 [RPC1] INFO txpool src/cryptonote_core/tx_pool.cpp:327 Transaction added to pool: txid <b862cc09f0c18f43d25cb082e69e56f028d3259acd836f0b1df7dc28bd595e0e> weight: 2598 fee/byte: 13837.6

2019-12-17 17:51:05.896 [RPC1] INFO txpool src/cryptonote_core/tx_pool.cpp:395 Pruning tx <b862cc09f0c18f43d25cb082e69e56f028d3259acd836f0b1df7dc28bd595e0e> from txpool: weight: 2598, fee/byte: 13837.6

2019-12-17 17:51:05.896 [RPC1] INFO txpool src/cryptonote_core/tx_pool.cpp:399 Pruned tx <b862cc09f0c18f43d25cb082e69e56f028d3259acd836f0b1df7dc28bd595e0e> from txpool: weight: 2598, fee/byte: 13837.6

2019-12-17 17:51:05.902 [RPC1] INFO txpool src/cryptonote_core/tx_pool.cpp:413 Pool weight after pruning is larger than limit: 18446744073709322844/648000000

Manual txn shove onto xmrchain w/ the raw hex, ^ is from the xmrchain daemon.

Looks like we're getting auto-pruned some how.

No, it's an unrelated thing.

Is your txpool full ?

"print_pool_stats"

moneromooo: paste.debian.net/hidden/f9a89ae4

The 18446744073709322844 says there's a bug in accounting in pool size.

This ought not prevent that tx from being mined though.

If that is the problem, a restart should fix it. Plus relay_tx if you want to not wait 4 hours.

Wait a bit first.

I'm going to look whether there's anything I'd like to get from gdb...

that was from snipas node, not the affected one

OK

but seems his node also doesn't like the tx

Any interesting exceptions ? That is, not the weak pointer one, nor the randomx one ?

I'm out atm so can't look. snipa will be back in ~15m

Sorry, just got back. That error I pasted is from xmrchain, I'll get it's pool size, but it's updating fine overall.

Also, relay_tx isn't playing nice on the affected node, and it's been restarted.

moneromooo - The logs you wanted from the debug: pastebin.com/raw/tdqqkdyW Nothing useful in there that I can see offhand.

Yes, looks like al txes (presumably included the one that was said to be lingering) got into the block template...

There's 29 lingering, but yes, they all got injected in that template.

Start another daemon, make sure it's connected to the first one. Wait till the first one relays. See if the new daemon receives that tx.

The queue with the issue just cleared itself, I'm getting our backlogged txnid's to see if they just magically managed to broadcast and got happy.

Interesting, looks like they all just made it onto the network, 2-3 hours late, but they made it there.

so weird

Hello again, I am still struggling with my key-image problem,

I created a new question here monero.stackexchange.com/questions/…es-vartime-step-by-step-explanation

I tried to read the whitepaper but it is quite heavy

That reminds me, shen wrote a review of that function.

I think it is here github.com/monero-project/research-…per/ge_fromfe_writeup/ge_fromfe.pdf

Oh, good.

Oh, god! :)