06:58:35 Are there any other Telegram regional groups? The Polish* one doesn't seem to have a moderator anymore. 06:58:36 Added on Moner.ooo: @MoneroEsp @moneroitalia @moneroger @MoneroCN @XMR_RU @monerobrasil @monerogr @moneroPL (*) @moneroNL 06:58:38 Does this group no longer exist? @monerofrance 10:02:23 Can somebody please give me monero.social credentials? I hate matrix.org... it's buggy 10:14:18 ah nice! thought it was invite only somehow... thanks! 10:15:31 venture4487: nvmitsmatrixdotorg has contacted you with that info 10:16:41 resolved already :) 10:29:05 directly because of the bots DM? or did you not read it and discover the method yourself (also ok) 10:35:18 the bots DM helped, didn't know the correct url (matrix.monero.social) 11:09:06 thank you for this trust pilot review :')) 12:51:39 sometimes his coverage is a bit selective. Same goes for monero.observer. Both of them don't give enough attention to kuno fundraisers and in general ignore certain efforts. I asked rottenwheel specifically to include my work around monerochan.cash and monerochan.news in the recent revuo and he ignored it. https://www.reddit.com/r/Monero/comments/1dfj7rs/new_tools_added_to_moneroc 12:51:40 hancash/ I went out of my way to retweet his stuff and make him feel seen. But it seems like he has personal problem with me. (also see the abrasive comments under my CCS proposal) 12:53:27 so while it is not a strict thumbs down from me, I think the CCS should only be approved if he changes his behavior. 13:28:06 Okay I just gave him a thumbs down. Because he seems to think this is funny and he does not take it seriously. 13:28:56 https://matrix.monero.social/_matrix/media/v1/download/kernal.eu/KNHIQarJCZfgvxxNJpxnrpgQ 13:29:20 I took a look at the CCS proposal from back in the day. First he spells the name correctly. 13:29:28 https://matrix.monero.social/_matrix/media/v1/download/kernal.eu/HhbwMDhmwvxUixEzjQgOqJed 13:29:40 and then he intentionally spells it wrong in an insulting way. 13:31:12 https://matrix.monero.social/_matrix/media/v1/download/kernal.eu/OXfvkeCaeSkUWFGoJmIqOmYx 13:31:15 he continues to just attack my character without adding any constructive criticism of the project (which I delivered on and moved forward with my own money after the CCS was closed down) 13:31:29 https://dayssincelastdramainmonerocommunitygrouponmatrixorirc.xyz/ 13:31:58 https://x.com/spirobel/status/1591350820708442112 13:44:36 sometimes his coverage is a bit selective. Same goes for monero.observer. Both of them don't give enough attention to kuno fundraisers and in general ignore certain efforts. I asked rottenwheel specifically to include my work around monerochan.cash and monerochan.news in the recent revuo and he ignored it. https://www.reddit.com/r/Monero/comments/1dfj7rs/new\_tools\_added\_to\_mon 13:44:38 erochancash/ I went out of my way to retweet his stuff and make him feel seen. But it seems like he has a personal problem with me. (also see the abrasive comments under my CCS proposal) 16:10:36 I would like to introduce to you the “afk compiler” theory 16:10:38 Basically, you can’t be at your desk coding 25/7; most of us have lives, and some of us have very little time to actually do coding stuff 16:10:40 But we still think about the coding stuff while away, so we use chats like these ^^^ to substitute for the actual progress we want to be doing 16:10:42 Because we are less connected to the actual *work* involved, and much more connected to the words of others, if there is ever any disagreement, some people (especially on bad days) will treat the other party not like an actual person to discuss with, but rather like they are a “compiler error” and you just have to “rewrite your code” so that it will “compile”. They may 16:10:44 not be consciously thinking in such an absurd way, but the part of their subconscious that is thinking about coding might start seeping into the rest of their thinking. 16:10:46 Tl;dr “shut up and code” isn’t the answer, the answer is “shut up OR code” 16:45:05 wow excellent speech 👌 16:45:24 Lol 16:58:28 straight out of westworld 🤣 17:41:18 Has anyone tried to use the new `subtractfeefrom` with `monero-wallet-rpc`? https://github.com/monero-project/monero/pull/8861 . I've tried to get it to work, with no success. And the RPC docs aren't updated yet. 17:43:08 hm 17:44:05 does the example help Rucknium https://github.com/monero-project/monero-site/pull/2249/files 17:46:20 Thank you. I may try it. The -cli command is a string. It can be "all", "0,1", etc. I think I was confused by this. 17:47:03 But your proposed docs say that the -rpc input should be an array of ints. 17:48:18 Yes 17:48:32 Lmk how usability is 17:48:35 nice, does rpc support "all" also? 17:48:43 Nope 17:49:26 If it is desired, we could make the array [-1] mean "all" 17:50:12 we're lazy so -1 would stop us from learning what it means 17:50:56 Wow it worked. 17:51:28 i cant believe you didnt check the un merged pull requests docs 17:52:03 The bad part of the DX: I was inputting wrong params, but it didn't tell me the params were wrong. Instead, it told me that I didn't have enough unlocked balance. 17:52:12 (a joke, should be merged already and live, sorry) 17:52:17 If the docs get updated, that would be enough. 17:53:39 a powerful rpc call that should be part of every stressnet users arsenal 17:53:55 thank you jeffro256 17:54:20 I am basically using this to `sweep_all/`, but with multiple output addresses. So I query the unlocked balance and send all of it, then set the `subtract_fee_from_outputs`. 17:54:35 Yes this is for stressnet lol 17:55:33 I thought I'd be clever and use this new feature :) 18:04:54 Hey jeffro256 :) ruckmium_ told me I should consult you about what I can all fuck up for the user with MoneroSigner, do you have maybe in the next two days some time to talk about? 18:05:22 jeffro256: I don't think it's worth it. If someone is using monero-wallet-rpc programatically, the code already knows how many addresses they are sending to. If they want "all", then just make an array 1,2,...,N as the parameter. 18:06:20 vthor: Another possible problem I thought of: Insufficient entropy on wallet generation can allow thieves to steal from even airgapped wallets. 18:06:39 Thanks for following up with jeffro :) 18:07:28 entropy comes mostly vom the sha256 of the cam stream, or external from dices, you can choose your seed words only if you enable before 'low security' 18:10:42 rucknium: So, I use the same method for seed generation (without modification as seedsigner, except that I disable bring your own seed (without checksum) by default, because this is a perfect way for the user to shot his own foot. (so it is possible only after switch to 'low security and then the user gets shown a warning) 18:12:20 I do usualy what I'm saying. I'm only some time too busy to do it directly. 18:15:05 Sounds good to me. Of course, the Monero seed words are different from bitcoin seed words. You just need to convert things correctly. 18:15:55 vthor monero-python and monerophp have pretty straightforward implementations of generating monero seeds and encoding/decoding 18:21:45 And was still searching how to contact jeffro256.... 18:22:40 That was my thought exactly 18:23:20 recanman, I use the random and feed it like `monero.seed.Seed(hexlify(random_32_bytes_from_sha256)).phrase` to generate the monero seed, polyseed is don similar 18:23:23 @vthor: hi! Yeah I'd be down to chat about it. I won't claim that I can enumerate all possible failure points though.. 18:23:47 Looks good vthor 18:23:57 Your source of entropy is the camera? 18:25:20 yes it is the whole stream fed to the camera and at the and added the still image shot, +some hardware-id from the pi 18:26:02 in case of dices entropy comes from extern, but I wonder how many people will that actually do.... 18:26:11 Just wondering, why not /dev/urandom? 18:26:27 on the pi? 18:26:37 reminds me of some bitcoin hardware wallet that let you roll a dice hundreds of times for entropy 18:26:53 I could throw it additionally inside 18:27:13 strawberry: exactly that with dices. 18:27:15 and they had a python script to reproduce the seed from the rolls, to prove the firmware isnt evil 18:27:18 I would recommend that vthor, I'm not sure if you're getting sensor data from the camera or the normalized image itself 18:27:55 yes, is the same method (seedsigner), its only a modification from btc to xmr strawberry 18:28:10 You should include /dev/urandom. It's usually a bad idea idea to rely on one source of unproved randomness 18:28:34 https://security.stackexchange.com/questions/42428/is-generating-random-numbers-using-a-smartphone-camera-a-good-idea 18:29:03 recanman: would need to check again, how it is done. 18:29:06 oh im blind, this already works with dices? 18:29:17 yes 18:29:35 I concur with jeffro, urandom is 'proven' as it is used as cryptographically-secure source of entropy 18:29:44 realistically the camera data is fine, but reproducible with dice rolls is good for paranoid users 18:30:38 This answer gets into why just using a camera can fail: https://security.stackexchange.com/questions/42428/is-generating-random-numbers-using-a-smartphone-camera-a-good-idea/42430#42430 18:31:20 is this meant to run on a pi? haven't been following 18:31:37 Many sensors are designed to smooth out the signals they receive, same with firmware processors, and post-processors. Unless you know at a hardware level that you are getting raw values, the image data will likely be smoothed which decreases entropy 18:31:38 jeffro256, will do that, maybe it is already the case, need to check, but before ready for production will defenitly throw urandom there inside although not trusting urandom on pi (but how it is simply fed into sha256 I'n my understanding it should not f.. up the entropy as long it is not more then 50%, or I'm wrong? 18:31:50 So the original bitcoin seedsigner code isn't as good as it could be? 18:34:02 rucknium: I personaly think it is sound if you let the stream of the cam long enough moving the camera around - well, one should maybe not do it in complete darkness how the only entropy would then be the noise and pixel errors of the sensor. 18:34:35 I would think that a proven source of entropy be used as a minimum 18:34:46 @vthor: Theoretically, adding randomness and throwing it into a random oracle will never decrease entropy, so a perfect hash function will at least preserve entropy. In practice, cryptographic-ally secure hash functions are not perfect random oracles, but for most use cases, combining both image data and output from /dev/urandom and passing it to a secure hash function most likel 18:34:46 y won't make things worse, and will help in most cases 18:35:02 I would think that a proven source of entropy should be used as a minimum 18:36:51 jeffro256: thanks for conferming that, but now I wonder, so lets say I throw 100bits of entropy and 1 million zero-bytes throuh a sha256 stream, so the 100bits of entropy are still 100bits of entropy? 18:37:45 If sha256 is a cryptographically secure hash function then the answer would be yes 18:38:00 I'm not sure if it is considered one or not, just clarifying 18:40:01 In my last discousion with crytographers in #crypto and ##math they told me it is fine. 18:41:46 in case of polyseed if goes through pkdf aragon2 to create the seed, while for monero seed my knowledge ends from delivering the random to monero.seed.Seed 18:47:37 One method that could be more secure and more easily verifiable for paranoid users, while not requiring a camera is to 1) attach a hardware random number generator to the raspberry PI 2) attach a small num 0-9 pad and let the user whale on the numpad for however long they want. Then show the user the result of 1) and 2), and a hash of both, The hash will be used as the seed, but t 18:47:38 he user can at least check that the seed is cryptographically bound (i.e: a function of, has at least as much entropy as) to their random mashing of the numpad. Also, if the user enters nothing into the numpad, the hardware random number generator will make sure that there is true randomness, not relying on the details of photo capturing 18:48:08 there is btw the linux emulator executable https://github.com/DiosDelRayo/MoneroSigner/releases/download/v0.3.1/xmrsigner-0.3.1_x86_64_linux, win32 I still need to do, but probably will skip for the moment becaue I want first to have a working image for the build chain for the pi. 18:49:32 Some paranoid users may also not like that the camera could capture their face accidentally 18:50:23 jeffro256, who would do that? (only wonder) I would boot tails get monero-cli/gui and create a wallet, wrote down my seed, unplug the usb and walk away.... 18:51:05 Who would do which part ? 18:51:47 jeffro256, you need to mega paranoid, on a device you (can) take the microSD off and all is gone and bt/wifi is deactivated (you only can be sure if you castrate hardware wise) 18:54:42 With a camera, if the device is comprised, then your facial data and seed are potentially leaked. Without a camera, just your seed is lpotentially eaked 18:55:06 my scope is to deliver the MoneroSigner fork that was promised, but seriously, with all what I'm really paranoid about I don't want to have in another place then my head and hadware software only emphermeral. So I think with high paranoia or huge funds dices is probably the best way, IMO, but I doubt that a highly paranoid person would trust the entropy generated on the device.... 18:56:07 That's what the numpad would be for 18:56:35 People who want to roll dice can enter 1-6 18:57:57 jeffro256, that is right, but if you worry about that, why you would use it in the first place? yes people who want to roll dices can enter 1-6 (yet a bit complicated, think of changing that to make the UX better) and maybe later this year I will come back and will port back a diceware scanner to the device (but again cam) 18:59:41 And hiting on a num pad I think it's bad entropy as long it's only the input and not other things about the entry, I would personaly believe more randomness is provided from a white wall via cam stream us by a user using the numpad, but just my opinion. 19:01:03 That's what the hardware random number generator is for: true randomness based on provably random physical phenomenon 19:03:02 Next thing the os has in-/output from the kernel stripped (not verified yet), and that makes for me absolute sense. But again, a real paranoid person I doubt would use the device to generate the seed itself. I mean I would use it quick for 5-10xmr with cam, but all beyond, I would got with monero-gui/cli on tails. 19:04:58 Not making a guess that a picture of a white wall might maybe have enough entropy. You could always add it into the equation, but that's a form of randomness that realistically the user is going to have to rely on the device that it is correct; the user is not going to go through each pixel of the image and do the calculations by hand to make sure the seed was derived right. And e 19:05:00 ven if they did, they can't verify that the pixel values are actually correct measurements of light going into the camera. In short: the randomness from the camera is unverifiable to the paranoid user, so why just use a hardware device that is guaranteed to generate real true actual randomness? 19:07:55 IMHO the answer to "why not" is that vthor is going to do a direct port of bitcoin seedsigner to Monero. Doing more may be scope creep. 19:08:12 Fair enough 19:08:44 garanteed from whom and how? I'm in a lot of applications hyperparanoid, often my liberty and my live could depend on it. And I never used a randomness generated by a yubi key, but wrote the key to the yubikey. 19:09:42 rucknium, thank you for the translation :) 19:09:53 Pooling entropy sources is something that can be done trivially, honestly, it would be better if you just used /dev/urandom + the camera or just camera or whatever for now and focus on other functionality 19:13:09 I'm not so socially skilled and often write testaments instead of saying something so pecise, so that was really the compressed answer :) But I reasearched in the meanwhile that there should be a hwrng on the device. But 3-4 years ago I looked into it and I decided to not use the entropy on the device generated for secure communiction of my customers, so I guess it is worse as key material for something long living.... 19:13:52 recanman: ack, I think that how it will be done, if there are no other concerns about. 19:14:06 Sounds good vthor 19:14:12 forgot to paste bcm2708-rng 19:16:09 any further concerns, where I could screw the users funds? I plan to use the same monero-python library to sign the transactions, I surely will not write own code for that as long it is not necessary. 19:16:29 Is balance calculated on a hot device ? How are e-notes and key images transferred? Sorry I'm not super familiar with the original seedsigner project 19:17:49 Ah, how I have here collected knowledge, for multisign, do I understand it right that that one party needs to sign after another and then publich the transaction or is there a possibility that each party signs an publish the transaction and the miners merge it together? 19:18:12 First one 19:19:34 j​effro256: I think it needs to, but I'm not sure yet, I will make tests with oficial monero(-cli/gui) for offline signing. But I guess the hot wallet does provid all necessary data and its only singned on the device with checking the amount and target addresses before on device. 19:20:05 what are e-notes and key images? 19:21:33 the unsigned transaction will be transfered via animated QR (UR) from the view key only wallet, and in the same way back the signed transaction for pulishing to the hot view key only wallet. 19:22:02 recanman, thought so :( 19:23:42 Air gapped multisig is kinda hell in Monero right now since you need to 1) scan e-enotes with hot wallet, 2) send e-notes to cold wallet, 3) calculate partial keys, 4) retreive partial key images from cold wallet, 5) disseminate partial key images to other signers, 6) collect partial key images from other signers, 7) send other's partial key images to cold wallet, 8) construct par 19:23:42 tially signed tx on cold wallet 9) pull partial tx from cold wallet, 10) pass around transaction to other signers, 11) have final signer broadcast the transaction 19:23:59 For your first cycle, you might want to not worry about multisig ;) 19:24:31 FCMP+SA+L makes all this significantly easier since we don't have to sync partial key images 19:25:58 okay :) 19:26:09 is there somewhere a log for this room? 19:27:30 monerologs.net #monero-community 19:28:22 never mind, copied it in a text file. :) 19:28:29 e-notes = transaction outputs, key images = ed25519 points that show up in transaction inputs that keep Monero from being double spent. On Monero's current consensus protocol, you currently need to sync "partial" key images across participants during multisig refreshing 19:28:49 thank you syntheticbird :) 19:28:56 You will need to send key images from the cold wallet to the hot wallet to calculate your balance regardless of multisig 19:29:24 the private view key can only see incoming e-notes, not outgoign 19:29:37 the view key is not enough? 19:29:48 right 19:29:50 Sadly, no 19:30:07 The view-balance key will be enough once FCMP+SA+L and Jamtis are deployed 19:30:50 But until then, there needs to be 2 way communication between the cold and hot wallets to accurately display balance 19:32:05 heck, what I need to provide then? what I read until now I would have a hot view key only monero-cli instance, genarate a file with a unsigned transaction, copy it on my airgapped monero-cli instance, sign, export the signed transaction to a file, then copy it to the how wallet view key only to publish' :/ 19:34:39 jeffro256, how many times/scans? when there is a two way communication it's not really airgapped. IMO, I mean, I'm okay with the QR code in that case, but a real conection between both, then I would say it's a joke :/ 19:36:37 great to hear that partial key images don't need to be synced jeffro256, that really makes multisig so much easier 19:36:44 (with fcmp) 19:42:36 vthor what you are proposing works if the user knows exactly which tx outputs have been spent and which haven't throughout their history. However, if you want to display the user a balance and/or automatically select inputs when constructing txs without attempting a double-spend, then you need to send a list of all view-scanned e-notes to the cold wallet before constructing txs. T 19:42:38 hen the cold wallet will calculate key images for those owned e-enotes. You then need to send those key images back to the hot wallet. Then the hot wallet will automatically do decoy selection and input selection and output an unsigned transaction. Then you do as you say: send unsigned tx to the cold wallet, and then send signed tx to hot wallet and broadcast 19:43:52 Without importing key images, a view-only wallet doesn't know how to construct transactions since it doesn't know what is spent and what isn't 19:45:30 This functionallity exists on the monero-cli/gui side, right? On the monero-python side I will need to solve that, correct? 19:47:25 That I don't know... I will need to check if the monero CLI / GUI supports this 19:49:08 Do you know any software supporting it today? 19:50:01 I know `wallet2` supports it, but hopefully something higher level than that also does... 19:50:22 where is wallet2 to find? is that a lib? 19:51:59 Here's the commands for `monero-wallet-cli`: https://docs.monero.study/interacting/monero-wallet-cli-reference/#key-images 19:52:25 `export_key_images ` and `import_key_images ` 19:52:31 When I export a view key only wallet, I get in the QR code the address, view_key (I assume it is the private view key, or?) and wallet height, In total there are 4 keys in the wallet public/secret view key and public/secret spent key 19:53:36 yes private key view. If you see something that only says "view key", it's the private view key. 19:55:19 the private view key is derived from the private spend key, except in multisig wallets and really really old wallets 19:55:43 but when you export a view only wallet, you don't get the private spend key 19:57:04 okay, until there I get it, but from where come the partial key images? Are that keys related to the addresses? (not sure, but I think I read some days ago that each address gets own keys generated...) 19:58:06 Okay, it seems I will have some 1-2 lab days :D I head is smoking now. 19:58:07 don't worry about partial key images unless you're doing multisig 19:58:50 You just need to worry about normal/full key images for single singer wallets 19:59:16 ah, okay, don't want to be rude. But my stress level is extremly high and I would like to continue the conversation in the next two days if this is okay for you.? 19:59:25 key images are associated 1-to-1 with e-notes (transaction outputs) 19:59:33 Yep that's fine ! 20:00:10 Monero has a very steep learning curve for everyone when building infrastructure, so don't fret ;) 20:00:32 8) thank you (just in case I'm seem rude, it is not my intention, I'm only akward ;) And anybody can tell me anything straight in my face) 20:02:19 Have a great one everybody and thanks for the patience with me :) 20:02:27 Best of luck with MoneroSigner! I'll probably be lurking in these chat rooms if you need anything, just lmk 20:03:45 jeffro256: Did you test the `subtractfeefrom` with 16-output txs? 20:04:37 I am getting "subtractfeefrom transfers cannot be split over multiple transactions yet" in the monero-wallet-rpc return value and "E subtract_fee_from_outputs.size() && dsts.size() > BULLETPROOF_MAX_OUTPUTS - 1. THROW EXCEPTION: error::wallet_internal_error" in the RPC log 20:05:28 What's probably happening is that a change output is getting inserted in there somewhere 20:06:08 Yes. AFAIK I have specified exact change. It seemed to work with 15-output txs and I got exactly 15 outputs (i.e. no change) 20:06:13 Are you sure that that the sum of destinations amount + fee = sum of inputs? If it's lower, then a change output has to be made 20:06:21 Oh okay weird 20:06:30 I will check it out 20:06:37 I am not 100% sure. Maybe 75% sure. 20:14:35 "the private view key is derived from the private spend key" technically, you can pass arbitrary keys to monero-wallet-cli using "--generate-from-keys ..." 20:18:57 Does anyone have resources or projects using RPC pay? I remember playing with it and setting up a proof of concept a few years ago, but I can't find many examples of it being used now. 20:20:07 As far as I know, no. There are simply too many public nodes that work for free 20:23:17 multix: AFAIK, pay-for-RPC is being deprecated. 20:25:18 really? was it ever used in practice? 20:27:08 I thought the whole point was to add RPC payments early, so that if the number of free nodes falls then there is some incentive system waiting to be turned on 20:28:29 hopefully we don't get to the point where rpc payments are necessary, but it's defense in depth against big miners being the only ones running rpc nodes 20:31:10 multix F https://github.com/monero-project/monero/issues/9248 20:31:58 It wasn't used in practice AFAIK. If there was a use case, it was the suspected spam incident earlier this year when a lot of public RPC nodes were overloaded. Having to pay for RPC would have changed the incentives then. Paying customers could have been prioritized. But it wasn't used. Would it ever be used? 20:38:49 It is supported node side but dropped on the wallet side officially. Currently it is not actively maintained, and there aren't any services which depend upon it AFAIK 20:52:25 On second thought RPC payments do seem fairly useless, since it only takes 1 free node to be online for everyone to stop paying 20:52:39 In the case of an attack, chances are that 1 free node is a spy node 20:53:54 Albeit RPC payments never make the spy node problem worse, since the paid nodes would just shutdown 20:58:47 Good point. But depends on whether people know the spy node is a spy node or not 20:59:24 true, people might pay a premium to a "trusted" rpc provider, but those people are the same type to run their own nodes 20:59:28 Also an argument for more resilient wallet-daemon information protocols in general 21:13:43 plowsof: Rucknium huh, thats unfortunate, thanks for the info. 21:21:28 vthor: using the camera as an entropy source is a good idea. Each pixel should give about half a bit of quantization error, and even if you assume neighboring pixels are somewhat correlated, it should give you enough randomness with one frame. 21:21:30 True randomness sources would of course be even better, but it might be out of scope for the CCS 22:53:54 Hello! I have fully synchronized the latest version of the wallet. But I keep getting the error [P2Pool installation failed. Try starting the program with administrator privileges.]. I started the wallet on behalf of the administrator, and logged into Windows at all under the administrator account, and completely disabled all antiviruses and 22:53:54 firewalls. Help, what's wrong with installing P2Pool? Windows version 7 is professional. The node is fully synchronized (full node). ;(