01:49:25 <br-m> <kiersten5821:matrix.org> did the miner have to modify their client to mine these?
02:00:25 <br-m> <yushanren:matrix.org> I still don’t understand how you use AI to audit code. Just switch models to do the same work again.
02:41:03 <br-m> <jpk68:matrix.org> AFAIK most of these happened before the AI audits began (?)
03:00:35 <DataHoarder> 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
03:46:39 <br-m> <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
03:46:39 <br-m> <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),
03:46:39 <br-m> <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
03:46:39 <br-m> <gingeropolous> (https://github.com/monero-project/monero/blob/master/src/cryptonote_basic/tx_extra.h), which describes the field format as "varint tag; varint size; varint data[]" — implementing
03:46:40 <br-m> <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 https://mrelay.p2pool.observer/e/19u6oZQLM2RFWDRN ]
03:46:49 <br-m> <gingeropolous> i thought it might be from opus's work on the explorer
03:47:08 <DataHoarder> > the payload inside the wrapper is well-formed (2 additional pubkeys for a 2-output tx, consistent with a subaddress payment),
03:47:21 <DataHoarder> it's not, it says 65 bytes of length for +65 bytes
03:47:29 <DataHoarder> so there's already extra bytes
03:48:08 <DataHoarder> but indeed it's varint size, just in this case the size is *32 :D
06:09:00 <plowsof> can validate_address detect a burn address? e.g. the abbey * 25 word seed produces a primary address of https://monerotech.info/Home/AddressInfo?address=41fJjQDhryD11111111111111111111111111111111112N1GuTZeagfRbbKcALdcZev4QXGGuoLh2x36LhaxLSxCc2YDhi which is a valid address but...
06:16:26 <plowsof> abbey wallet _is_ a burn address right? or anyone can spend from it? confused 
06:34:40 <DataHoarder> plowsof: do you have the spend private key this derives to?
06:35:23 <DataHoarder> is that private key of 0?
06:39:03 <DataHoarder> funnily that fails on my checks against torsion and small orders
06:41:42 <DataHoarder> afaik you cannot multiply by 0 :)
06:44:50 <DataHoarder> (or well, every scalar mult of a point would land on the identity element
07:18:55 <plowsof> DataHoarder yes zero'd spend private key 
07:20:45 <plowsof> so abbey is not a burn address* 
07:21:00 <DataHoarder> well, it can't be spent, yet can be viewed
07:21:09 <DataHoarder> from what I understand you cannot make a proper proof
07:21:38 <plowsof> iirc sech1 knows about abbey
07:23:24 <DataHoarder> sadly I do extra checks on the address so can't add to explorer to see stuff
07:25:04 <DataHoarder> that one gets used in samples as well
07:34:03 <sech1> abbey wallet is not something you can just sync and spend whatever is there
07:34:16 <DataHoarder> 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
07:34:23 <sech1> but you can modify the wallet's code to ignore the zero spend key, and still spend money from there
07:34:42 <sech1> I think I recovered something like 0.1 XMR from there at one point :D
07:35:29 <DataHoarder> but yeah, it then gets mixed with other scalars, so it should still be possible to sign indeed
07:35:38 <DataHoarder> for subaddresses it's easier :D
07:36:04 <sech1> 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 :)
07:36:31 <DataHoarder> well yeah it's a degenerate condition where some values shouldn't add up to zero
07:38:51 <DataHoarder> lemme sync up, I want to get this added to the explorer
07:40:04 <plowsof> 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
07:40:04 <plowsof> this? 
07:40:47 <DataHoarder> I think that is way more strict in FCMP++/Carrot times
07:44:43 <DataHoarder> so many Failed to derive subaddress public key / Failed to generate key derivation from tx pubkey, skipping :)
07:47:18 <DataHoarder> 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
07:47:46 <DataHoarder> while allowing a view private key to exist for example
10:13:31 <DataHoarder> thanks for the 0.64 XMR reminder sech1 plowsof :)
10:14:16 <DataHoarder> I ended up scanning using my libraries... and ALSO building a transaction by hand using my libraries + CLSAG signing + BP+ proofs https://blocks.p2pool.observer/tx/8367d8b97545a884881817b74b3105a60f152b139a3dc0cea6d4a6e9a95a9d60
10:14:35 <DataHoarder> it spends this one https://blocks.p2pool.observer/tx/2a88cf38ccab2e663d1b58ba9e838f98ad866af09b26ef692ef17098c6e9cba6
10:15:31 <sech1> Looks like someone mined a block to abbey wallet? :D
10:19:38 <DataHoarder> none tx I can see do
10:21:41 <sech1> Just the amount is suspiciously close to the block reward (+some fat transactions in that block)
10:21:49 <sech1> Maybe someone mined a solo blocked and tried to withdraw it
10:22:01 <sech1> *solo block on a solo mining pool
10:30:37 <DataHoarder> anyhow plowsof definitely not a burn address
11:04:22 <plowsof> thnx
11:04:46 <plowsof> and congrats!
14:23:27 <br-m> <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?
14:50:07 <DataHoarder> you can
14:53:29 <DataHoarder> lemme try to build a spend proof :)
14:53:51 <br-m> <jpk68:matrix.org> I am syncing the wallet right now, for no particular reason
15:21:26 <sech1> Both me and DataHoarder already spent money from the abbey wallet :)
15:21:42 <DataHoarder> it's cleaned atm except two dust outputs
15:21:56 <DataHoarder> I use my own utilities/library/code though
15:24:09 <DataHoarder[m]> txid 8367d8b97545a884881817b74b3105a60f152b139a3dc0cea6d4a6e9a95a9d60
15:24:09 <DataHoarder[m]> SpendProofV13z5B1xFDPvLHxDgSv9s9kHKh68MmjoDzWKGNdYiNiXjzBhQB3o49DEiPiBXv5APtmChQVWR3LLfvSd4VdncgkARHXXYHTUBxJ253jX43EjbG2QhZSQAAwvewHMtTDwey2NSTAAj1xpvPg9hWE1wUcZLFXVYrupibDY3ijJKaL6Z56ZHUEBKFaaVEXt2LZy4EGkHsKeT89P3b69ViZ6mUUjuc6cRo7WY3xJXXxMagz2bJZwQRH2feCN4GghQDg7nWrdKHmBXu5GhQHyRLwHoiAsn58bCBQ9B3SxCYWmx92K9WaVmZuU1XTC58HVW [... too long, see https://mrelay.p2pool.observer/e/xoO1tZQLWEpsQzho ]
15:24:31 <DataHoarder[m]> verifies as good in Monero GUI on Check Transaction / Reserve :)
15:24:40 <DataHoarder[m]> (also generated with my own tools!)
15:25:45 <DataHoarder> if you are wondering it's ring member #10 (2f9b...) with x = 2bb2f071cfbfcefad6180aad0cfd64ce41bd2556a206995d3e06c8a56569f705
15:27:30 <DataHoarder> 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
15:48:32 <br-m> <jpk68:matrix.org> On my end, it has 20 XMR in it?
15:50:14 <br-m> <jpk68:matrix.org> But the outputs are invalid
15:52:32 <DataHoarder> all the images been spent
15:52:38 <DataHoarder> lemme see
15:52:49 <br-m> <jpk68:matrix.org> I'm just using Feather
15:54:17 <DataHoarder[m]> it'll fail
15:54:30 <DataHoarder[m]> @jpk68:matrix.org: list of scanned outputs and status of key images https://privatebin.net/?e6326e61fcaffe65#rc5YChFMvAjeRcub3UQutepyK3osPyc7FRff1meixeK
15:54:43 <DataHoarder[m]> and account/index in wallet
15:55:14 <DataHoarder[m]> spent status = 0 are unspent, only some dust :)
15:56:13 <br-m> <jpk68:matrix.org> Thanks for the 30 cents ;)
15:58:03 <DataHoarder> well you have to figure out how to spend them directly
15:58:19 <DataHoarder> but x value and the blind commitment is there, that is all you need really
15:59:19 <br-m> <jpk68:matrix.org> Maybe this isn't worth 30 cents, lol
15:59:50 <br-m> <jpk68:matrix.org> Time to just try and find a quarter on the street :)
16:00:12 <DataHoarder> it doesn't cover its own fee with whatever suggested one it has :)
16:00:29 <br-m> <jpk68:matrix.org> Yeah, that's what I ran into
16:01:03 <DataHoarder> I built the tx by hand and including those two dust as inputs was a bother so I didn't
16:30:39 <br-m> <untraceable> "Can't create transaction. Unexpected error. Not enough usable money in top 128 inputs. (186.018271163767). To fund minimum output sum: (333.00050800000)."
16:31:15 <br-m> <untraceable> Whats this mean exactly...? wallet says spendable funds are 1581.666
16:31:42 <br-m> <untraceable> trying to send funds to spam wallet
16:34:43 <br-m> <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
17:13:14 <br-m> <kiersten5821:matrix.org> didnt the limit used to be like 146?
17:18:39 <br-m> <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
17:23:24 <br-m> <ofrnxmr:xmr.mx> @untraceable: Yes, max inputs for fcmp is 128
17:23:26 <br-m> <ofrnxmr:xmr.mx> We only contruct txs in.. powers of 2? 2 4 8 16 32 64 128(max)
17:24:08 <br-m> <ofrnxmr:xmr.mx> You can try transfer_split, which will construct more than 1 tx, or reduce the amount being sent
17:33:16 <br-m> <kiersten5821:matrix.org> so i cant spend 3 inputs after the upgrade?
17:38:08 <nioc> I believe dummy inputs are added 
17:51:02 <br-m> <untraceable> Oops I thought I was typing in the stressnet channel. And ok thanks I get it now.
18:03:37 <br-m> <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
18:13:28 <br-m> <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.
19:57:22 <br-m> <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. 
19:57:39 <br-m> <jeffro256> nioc: Dummy inputs are not implemented in the current FCMP++ codebase 
20:08:00 <br-m> <kayabanerve:matrix.org> Large-input TXs take a long time to verify, and that isn't unique to FCMP++.
21:30:45 <nioc> jeffro256 thx for the clarification