<kiersten5821:matrix.org> did the miner have to modify their client to mine these?

<yushanren:matrix.org> I still don’t understand how you use AI to audit code. Just switch models to do the same work again.

<jpk68:matrix.org> AFAIK most of these happened before the AI audits began (?)

kiersten5821: for this one, Monroe gathers txs even ones that don't normally decode tx extra. Tx extra is a convention only if you want the wallet to decode it OOB I guess

<gingeropolous> DataHoarder: , @jpk68:matrix.org "Standard serialization is 04 <varint pubkey-count> <keys> with no byte-length. Whoever built this tx TLV-encoded the field (tag, length, value) — so a standard parser reads 65 as "65

<gingeropolous> pubkeys", expects 2,080 bytes, and fails. Notably, the payload inside the wrapper is well-formed (2 additional pubkeys for a 2-output tx, consistent with a subaddress payment),

<gingeropolous> which points to a deliberate but buggy third-party wallet serializer, not corruption. A likely culprit is the misleading comment in monero's own tx_extra.h

<gingeropolous> (github.com/monero-project/monero/bl…ter/src/cryptonote_basic/tx_extra.h), which describes the field format as "varint tag; varint size; varint data[]" — implementing

<gingeropolous> from that comment produces exactly these bytes. Consensus doesn't validate tx_extra contents (see the long-running discussion in monero#6668[... more lines follow, see mrelay.p2pool.observer/e/19u6oZQLM2RFWDRN ]

<gingeropolous> i thought it might be from opus's work on the explorer

> the payload inside the wrapper is well-formed (2 additional pubkeys for a 2-output tx, consistent with a subaddress payment),

it's not, it says 65 bytes of length for +65 bytes

so there's already extra bytes

but indeed it's varint size, just in this case the size is *32 :D

can validate_address detect a burn address? e.g. the abbey * 25 word seed produces a primary address of monerotech.info/Home/AddressInfo?ad…cALdcZev4QXGGuoLh2x36LhaxLSxCc2YDhi which is a valid address but...

abbey wallet _is_ a burn address right? or anyone can spend from it? confused

plowsof: do you have the spend private key this derives to?

is that private key of 0?

funnily that fails on my checks against torsion and small orders

afaik you cannot multiply by 0 :)

(or well, every scalar mult of a point would land on the identity element

DataHoarder yes zero'd spend private key

so abbey is not a burn address*

well, it can't be spent, yet can be viewed

from what I understand you cannot make a proper proof

iirc sech1 knows about abbey

sadly I do extra checks on the address so can't add to explorer to see stuff

that one gets used in samples as well

abbey wallet is not something you can just sync and spend whatever is there

plowsof: from what I look at cryptonote derivation this is true as long as it got sent to the main address, the extension is also zero. zero+zero = zero, x G + y T where both x and y are zero, too

but you can modify the wallet's code to ignore the zero spend key, and still spend money from there

I think I recovered something like 0.1 XMR from there at one point :D

but yeah, it then gets mixed with other scalars, so it should still be possible to sign indeed

for subaddresses it's easier :D

I don't remember exactly, but if you try to restore abbey wallet, it will see incoming transfers, but you can't spend it - the wallet gives an error. Find where in the code this error is triggered, comment it out, and voila :)

well yeah it's a degenerate condition where some values shouldn't add up to zero

lemme sync up, I want to get this added to the explorer

if i put a 'weird' address accidentally on purpose, and withdraw a large amount, but claim the sender is at fault for sending to a "burn address" / not validating it, and request a refund but secretly have already swept from that address - should validate_address stop this? and DataHoarders "checks against torsion and small orders" would stop

this?

I think that is way more strict in FCMP++/Carrot times

so many Failed to derive subaddress public key / Failed to generate key derivation from tx pubkey, skipping :)

the right way to make a burn address is to just expose a way to derive the spend/view pubkeys from a public value so it can't be reversed

while allowing a view private key to exist for example

thanks for the 0.64 XMR reminder sech1 plowsof :)

I ended up scanning using my libraries... and ALSO building a transaction by hand using my libraries + CLSAG signing + BP+ proofs blocks.p2pool.observer/tx/8367d8b97…5a60f152b139a3dc0cea6d4a6e9a95a9d60

it spends this one blocks.p2pool.observer/tx/2a88cf38c…f98ad866af09b26ef692ef17098c6e9cba6

Looks like someone mined a block to abbey wallet? :D

none tx I can see do

Just the amount is suspiciously close to the block reward (+some fat transactions in that block)

Maybe someone mined a solo blocked and tried to withdraw it

*solo block on a solo mining pool

anyhow plowsof definitely not a burn address

thnx

and congrats!

<jpk68:matrix.org> This is probably a dumb question, but you can't spend money from the abbey wallet because... the spend key is itself invalid though you can still derive valid one-time addresses from it?

you can

lemme try to build a spend proof :)

<jpk68:matrix.org> I am syncing the wallet right now, for no particular reason

Both me and DataHoarder already spent money from the abbey wallet :)

it's cleaned atm except two dust outputs

I use my own utilities/library/code though

txid 8367d8b97545a884881817b74b3105a60f152b139a3dc0cea6d4a6e9a95a9d60

SpendProofV13z5B1xFDPvLHxDgSv9s9kHKh68MmjoDzWKGNdYiNiXjzBhQB3o49DEiPiBXv5APtmChQVWR3LLfvSd4VdncgkARHXXYHTUBxJ253jX43EjbG2QhZSQAAwvewHMtTDwey2NSTAAj1xpvPg9hWE1wUcZLFXVYrupibDY3ijJKaL6Z56ZHUEBKFaaVEXt2LZy4EGkHsKeT89P3b69ViZ6mUUjuc6cRo7WY3xJXXxMagz2bJZwQRH2feCN4GghQDg7nWrdKHmBXu5GhQHyRLwHoiAsn58bCBQ9B3SxCYWmx92K9WaVmZuU1XTC58HVW [... too long, see mrelay.p2pool.observer/e/xoO1tZQLWEpsQzho ]

verifies as good in Monero GUI on Check Transaction / Reserve :)

(also generated with my own tools!)

if you are wondering it's ring member #10 (2f9b...) with x = 2bb2f071cfbfcefad6180aad0cfd64ce41bd2556a206995d3e06c8a56569f705

but yeah a lot of scalar additions and whatnot just cancel out or are also 0, the default wallet doesn't like this stuff too much so it can't track spends either

<jpk68:matrix.org> On my end, it has 20 XMR in it?

<jpk68:matrix.org> But the outputs are invalid

all the images been spent

lemme see

<jpk68:matrix.org> I'm just using Feather

it'll fail

@jpk68:matrix.org: list of scanned outputs and status of key images privatebin.net/?e6326e61fcaffe65#rc…vAjeRcub3UQutepyK3osPyc7FRff1meixeK

and account/index in wallet

spent status = 0 are unspent, only some dust :)

<jpk68:matrix.org> Thanks for the 30 cents ;)

well you have to figure out how to spend them directly

but x value and the blind commitment is there, that is all you need really

<jpk68:matrix.org> Maybe this isn't worth 30 cents, lol

<jpk68:matrix.org> Time to just try and find a quarter on the street :)

it doesn't cover its own fee with whatever suggested one it has :)

<jpk68:matrix.org> Yeah, that's what I ran into

I built the tx by hand and including those two dust as inputs was a bother so I didn't

<untraceable> "Can't create transaction. Unexpected error. Not enough usable money in top 128 inputs. (186.018271163767). To fund minimum output sum: (333.00050800000)."

<untraceable> Whats this mean exactly...? wallet says spendable funds are 1581.666

<untraceable> trying to send funds to spam wallet

<boog900> @untraceable: Sounds like there is a limit on the number of inputs (128) and you don't have enough combined XMR in your top 128 outputs by XMR value to send that much XMR in 1 tx

<kiersten5821:matrix.org> didnt the limit used to be like 146?

<boog900> @kiersten5821:matrix.org: The limit was on the size of the tx rather than the number of inputs, you can have a tx up to 150 kb, IIRC that gives you around 200

<ofrnxmr:xmr.mx> @untraceable: Yes, max inputs for fcmp is 128

<ofrnxmr:xmr.mx> We only contruct txs in.. powers of 2? 2 4 8 16 32 64 128(max)

<ofrnxmr:xmr.mx> You can try transfer_split, which will construct more than 1 tx, or reduce the amount being sent

<kiersten5821:matrix.org> so i cant spend 3 inputs after the upgrade?

I believe dummy inputs are added

<untraceable> Oops I thought I was typing in the stressnet channel. And ok thanks I get it now.

<jpk68:matrix.org> @ofrnxmr:xmr.mx: Is this just a relay rule that coencides with the fork, or does it have to do with tree building or something

<torir:unredacted.org> @jpk68:matrix.org: The 128 input limit for FCMP is a concensus rule, added to prevent DOS attacks since large FCMP transactions take a long time to verify.

<jeffro256> @ofrnxmr:xmr.mx: Not true, the input selection code prefers powers of 2, but any number of inputs in [1, 128] can be spent in a single tx.

<jeffro256> nioc: Dummy inputs are not implemented in the current FCMP++ codebase

<kayabanerve:matrix.org> Large-input TXs take a long time to verify, and that isn't unique to FCMP++.

jeffro256 thx for the clarification