00:14:51
miguel:
I am following the build instructions on github but when I run make -j$(nproc) it fails to build. the only thing I can see is it says ccache is found but unusable
00:15:04
miguel:
but I checked and I can certainly use ccache
00:17:58
omurad:matrix.org:
ccache is probably not the issue, there's likely another error further up in the logs
00:20:45
miguel:
This is everything that I see https://bpa.st/BUMA
00:37:21
omurad:matrix.org:
You're on the newest version of CMake, which doesn't seem to play nicely with v3.10+
00:42:41
miguel:
so I ran `cmake -Wno-dev` and then `make -j$(nproc)` and that appears to have worked
00:42:59
miguel:
my repo is an absolute shitshow now, but the binary did get built xD
03:22:39
kiersten5821:matrix.org:
hi > <@plowsof:matrix.org> hello from matrix org account
04:06:47
ofrnxmr:xmr.mx:
miguel: This should be fixed a long time ago
04:07:17
ofrnxmr:xmr.mx:
https://github.com/monero-project/monero/issues/9932
04:07:18
ofrnxmr:xmr.mx:
fixed here: https://github.com/monero-project/monero/issues/9932#issuecomment-2910782334
06:58:56
hbs:matrix.org:
Bumped into an issue while testing the upcoming version of Monerujo, the format of the monero_wallet URIs it supports differs from the format supported by Cake Wallet. I filed an issue almost a year ago to bring clarity to the URI specification but it has remained unnoticed until now.
06:58:57
hbs:matrix.org:
I am therefore calling all Monero wallet developers to look into the issue related to Monerujo (https://github.com/m2049r/moneroju-issues/issues/1) and to the issue related to the URI spec (https://github.com/monero-project/monero/issues/10168) so they can consider vetting the proposed changes, bringing clarity and advanced fe [... too long, see https://mrelay.p2pool.observer/e/07yVn-cKM3BPOEhs ]
08:54:54
321bob321:
There here somewhere
10:07:00
plowsof:
hbs step 1 first remove the "address=" param from your uri, its a path and not supported in wallet2 afaict, noted by the "hierarch." and the resulting error when attempting it with wallet-rpc - if this is confusing suggest clarification, im not concerned with third party not adhering to uri specs. step 2: the monero gui will interpret "height" as
10:07:01
plowsof:
blockheight OR date when creating a wallet depending on value entered, not sure if this is implemented by wallet2 but think logically - passing a date has to then be converted into an estimation blockheight and can be inaccurate (reg inaccurate height estimations ofrnxmr linked https://github.com/monero-project/monero/pull/10165/changes) step 3:
10:07:01
plowsof:
make an issue on docs so ofrnxmr knows about the Note reg payment id not being accepted anymore in parse_uri / make_uri (confirmed just now) step 4: reg name, look at create_wallet wallet-rpc call - it accepts a `filename`, use human language to justify the inclusion of a filename param in the uri instead of your proposed `name`
10:13:15
plowsof:
also hbs "calling all Monero wallet developers" i left a similar comment on the other issue which had no response from you. and you have just had feedback from monerujo dev on the issue. do you actually want feedback or are you looking for people to agree with you
11:08:47
hbs:matrix.org:
plowsof: It's not mentioned in the original spec as part of the path hierarchy, hence my proposal to clarify the spec. Unfortunately Cake so far has considered it as a parameter (the column where the address name appears is called Parameter, so this is a perfectly valid interpretation).
11:10:05
hbs:matrix.org:
plowsof: I don't want people to agree with me, I want people to realize there's an issue to be debated to improve things. I answered @m2049r:matrix.org latests comment 4 hours ago, I don't see any more recent one, is that the one you had in mind?
11:14:45
plowsof:
kind -> hierarchy. , again, if you think it's an issue submit a suggestion to clarify.
11:16:10
plowsof:
hbs we're not even at any step yet, you seem to think mentioning "all wallet devs" will tag them should they happen to read the backlog
11:18:13
hbs:matrix.org:
plowsof: Could you please read what I wrote? The document https://github.com/monero-project/monero/blob/master/docs/URI_SCHEME.md DOES NOT HAVE a kind column for describing the monero_wallet URIs, that column is only present for the monero scheme, this is the reason why I opened the issue in the first place, to propose a clarification of the spec!
11:20:18
plowsof:
great, lets suggest improvements first, step by step instead of coupling them with your needs/wants
11:22:42
plowsof:
and ignoring my comments for those needs/wants
11:34:03
ofrnxmr:xmr.mx:
monero_wallet:41pr4B7Cw6Ke4C54ngcy2FBVVGCLAzhi1PgMy68baMMYW7DXq9C8SS42HCaPyc7wyVZFaF8bJJEtq6eZkXT8yCFWR3eRbB9?
11:34:04
ofrnxmr:xmr.mx:
address=41pr4B7Cw6Ke4C54ngcy2FBVVGCLAzhi1PgMy68baMMYW7DXq9C8SS42HCaPyc7wyVZFaF8bJJEtq6eZkXT8yCFWR3eRbB9&view_key=41bedfd209fa9df3879fbbabddee27bd1b03d0a4b812340f8959b0d9de576a06
11:34:16
ofrnxmr:xmr.mx:
Why have the address specified twice?
11:35:21
sech1:
because it can be a subaddress?
11:35:26
sech1:
just guessing
11:36:11
ofrnxmr:xmr.mx:
its for restoring a wallet
11:36:28
ofrnxmr:xmr.mx:
So would have to be primary
11:36:58
ofrnxmr:xmr.mx:
Cake docs https://docs.cakewallet.com/faq/glossary/uri-scheme/#universal-wallet-restore-format
11:36:59
ofrnxmr:xmr.mx:
Cake example
11:36:59
ofrnxmr:xmr.mx:
[... more lines follow, see https://mrelay.p2pool.observer/e/hIqQp-cKUXIyZ0F4 ]
11:39:15
ofrnxmr:xmr.mx:
> Cake Wallet for example expects (or at least expected until recently) the address to be provided in an address parameter in the query string.
11:39:15
ofrnxmr:xmr.mx:
i don't think this is correct. I dont recall cake's doc changing for years
11:46:31
ofrnxmr:xmr.mx:
Cake's internal scheme uses address as a parameter: https://docs.cakewallet.com/faq/glossary/uri-scheme/#cake-restore-format
11:46:33
ofrnxmr:xmr.mx:
cakewallet:monero-wallet?address=467iotZU5tvG26k2xdZWkJ7gwATFVhfbuV3yDoWx5jHoPwxEi4f5BuJQwkP6GpCb1sZvUVB7nbSkgEuW8NKrh9KKRRga5qz&spend_key=029c559cd7669f14e91fd835144916009f8697ab5ac5c7f7c06e1ff869c17b0b&view_key=afaf646edbff3d3bcee8efd3383ffe5d20c947040f74e1110b70ca0fbb0ef90d&height=100000
12:02:13
hbs:matrix.org:
@ofrnxmr:xmr.mx: This doc mentions a scheme of monero-wallet instead of monero_wallet too
12:08:01
ofrnxmr:xmr.mx:
Yeah, cuz cake does cake things
12:09:41
hbs:matrix.org:
to be compatible with the maximum of wallets for as long as the spec is unclear > <@ofrnxmr:xmr.mx> Why have the address specified twice?
12:09:50
ofrnxmr:xmr.mx:
adaik, monero-wallet and monero_wallet are interchangeable in cake
12:10:13
ofrnxmr:xmr.mx:
@hbs:matrix.org: Restoring multiple wallets at once?
12:10:35
hbs:matrix.org:
@ofrnxmr:xmr.mx: wallet software I should have said
12:11:04
ofrnxmr:xmr.mx:
delete the address= and it should be compatible with all walleta
12:11:25
ofrnxmr:xmr.mx:
If its not, the wallet is using a non-standard spec
12:11:58
hbs:matrix.org:
@ofrnxmr:xmr.mx: last I had checked cake did not support the address in the path portion of the URI, will test again
12:12:18
ofrnxmr:xmr.mx:
cakes example says they do
12:12:26
ofrnxmr:xmr.mx:
i will try now
12:17:07
ofrnxmr:xmr.mx:
works fine
12:18:22
ofrnxmr:xmr.mx:
I have an older version of monero.com (5.6.0) and qr restore is broken
12:18:22
ofrnxmr:xmr.mx:
Cake 5.8.0 is not broken
12:18:58
ofrnxmr:xmr.mx:
Broken = it doesnt accept even their own examples
12:19:23
hbs:matrix.org:
Works with monero.com 5.9.0
12:19:27
hbs:matrix.org:
\o/
12:19:40
hbs:matrix.org:
So this is probably a recent change indeed
12:20:03
hbs:matrix.org:
Never the less I think it is important to clarify the spec to avoid such drama
12:22:18
ofrnxmr:xmr.mx:
cake has it clarified in theirs, but theirs was still completelt broken.
12:22:18
ofrnxmr:xmr.mx:
i dont know whay heirarch. ? Query fragment mean
12:23:10
hbs:matrix.org:
hierarchy if the path portion of the URI (the one after the URI scheme in the absence of authinfo + host / port)
12:23:29
hbs:matrix.org:
The fragment is the part introduced by a hash (pound) sign.
12:23:55
ofrnxmr:xmr.mx:
Could jist be simplified, like. Path vs param
12:24:31
ofrnxmr:xmr.mx:
@hbs:matrix.org: tx_description is not kntroduced by a # sign
12:24:50
plowsof:
£ time for a cup of tea
12:24:58
hbs:matrix.org:
@ofrnxmr:xmr.mx: It should as per the table on https://github.com/monero-project/monero/wiki/URI-Formatting, but it is not in the examples provided!
12:28:07
plowsof:
the example wants us to end with description? using "&"? how to describe that correctly if so
12:30:06
hbs:matrix.org:
plowsof: The table should describe tx_description as being a parameter, in which case both examples would be correct, ?tx_description=.... when tx_description is the first parameter in the query string, ...&tx_description=.... when there are preceding params.
12:30:46
Cindy_:
also this is my opinion
12:30:48
plowsof:
are "?" and "&" interchangeable delimiters for things in URI land? i dont know the significance
12:30:59
Cindy_:
the seed should be a base64 of the seed
12:31:05
Cindy_:
the seed paramter*
12:31:31
Cindy_:
and not the polyseed/24-word encoding of the seed
12:31:35
hbs:matrix.org:
plowsof: ? introduces the query string, within the query string parameters are separated by ampersands
12:31:38
Cindy_:
it wastes too much URI space
12:32:11
hbs:matrix.org:
Cindy_: can you decode base64 in your head?
12:32:21
Cindy_:
this is literally a URI
12:32:25
Cindy_:
it is decoded by a program
12:32:27
Cindy_:
not by a human
12:32:56
hbs:matrix.org:
Cindy_: 99% of the scams are due to people not checking URIs, maybe it's time humans start doing just that?
12:33:24
hbs:matrix.org:
Oh and base64 of the seed would consume 33% more space than the actual seed
12:33:25
Cindy_:
just saying, i don't like how the specs say the "seed" parameter is required to be a 24-word/polyseed representation of the seed
12:33:34
Cindy_:
because it wastes too much space
12:33:54
Cindy_:
"Oh and base64 of the seed would consume 33% more space than the actual seed" 24-word/polyseed consumes 160%+ more space than the actual seed
12:34:31
Cindy_:
actually 160% is too small
12:34:37
Cindy_:
it would probably be 500%
12:35:02
hbs:matrix.org:
I think you assume seed to be the secret derived from the mnemonic? I think in this spec seed means the mnemonic
12:35:07
plowsof:
spend+view keys rather than mnemonic right? this is also supported to save the most space afaict
12:35:26
Cindy_:
i meant seed key rather than mnemonic yeah
12:35:53
Cindy_:
(the key encoded in hex/base64 or whatever, rather than in mnemonic)
12:35:59
hbs:matrix.org:
plowsof: Though using hex is bad for conciseness
12:36:40
Cindy_:
plowsof: if the spend+view keys are derived from the seed key, then wouldn't it save extra space storing the seed as hex?
12:36:50
Cindy_:
it would be one 32-byte seed
12:36:57
Cindy_:
rather than a pair of 32-byte keys
12:37:33
plowsof:
molly wallet can restore a full wallet from just the spend key iirc
12:37:45
hbs:matrix.org:
Cindy_: It's not really about storage efficiency but conformance with what wallet software expect. I have yet to see a mobile Monero wallet which asks for the seed key instead of the spend/view key when restoring a wallet. Have you met such a beast?
12:37:46
Cindy_:
oh wait
12:37:48
plowsof:
what are they called... deterministic wallets?
12:37:52
Cindy_:
seed key == spend key
12:37:59
plowsof:
ah
12:38:02
hbs:matrix.org:
plowsof: Only if the wallet used a deterministic wallet though
12:38:03
Cindy_:
the view key is derived from the spend key
12:38:08
Cindy_:
now i remember :P
12:38:18
hbs:matrix.org:
Cindy_: Not necessarily
12:38:20
plowsof:
asking permission to say a rot13 joke
12:38:44
hbs:matrix.org:
plowsof: You'll ask for forgiveness after, bring it on
12:39:09
Cindy_:
hbs: but doesn't CryptoNote say that?
12:39:12
plowsof:
ok so ROT13 does not add any size to the seed what so ever.. zero.. none and adds encryption with zero drawbacks.
12:39:21
plowsof:
sorry
12:39:30
Cindy_:
the seed is the spend key, and the view key is derived from the spend key
12:39:53
Cindy_:
if your wallet software doesn't follow this, then well uhh.. good luck :P
12:39:57
hbs:matrix.org:
Cindy_: The deterministic wallets derive the view key from the spend key, but technically they are independent
12:39:57
plowsof:
👍
12:40:19
Cindy_:
yes they're independent
12:40:28
Cindy_:
but to prevent any headaches with compatibility and such
12:40:35
Cindy_:
wallets just use the same algorith
12:40:46
hbs:matrix.org:
We are so lucky the wallet software (end user and libraries) support setting them independently, otherwise atomic swaps would not be possible > <Cindy_> if your wallet software doesn't follow this, then well uhh.. good luck :P
12:40:53
plowsof:
if part of the spend key is provided and part of the address - our device could brute force the winning seed to reduce space even further
12:41:21
hbs:matrix.org:
plowsof: Proof of Wallet!
17:42:26
sgp_:
Skylight Wallet for iOS TestFlight is now available: https://testflight.apple.com/join/YSjKgHQ6
17:46:38
hbs:matrix.org:
@sgp_: Does Skylight Wallet support monero_wallet URIs for restoring wallets?
17:50:31
sgp_:
Not currently
23:49:27
geonic:
PSA: the software linked above is being marketed by a senior director at a blockchain surveillance company
23:49:54
geonic:
sgp_: a message like that would be great