<m​onerooo:monero.social> Are there any other Telegram regional groups? The Polish* one doesn't seem to have a moderator anymore.

<m​onerooo:monero.social> Added on Moner.ooo: @MoneroEsp @moneroitalia @moneroger @MoneroCN @XMR_RU @monerobrasil @monerogr @moneroPL (*) @moneroNL

<m​onerooo:monero.social> Does this group no longer exist? @monerofrance

<v​enture4487:matrix.org> Can somebody please give me monero.social credentials? I hate matrix.org... it's buggy

<v​enture:monero.social> ah nice! thought it was invite only somehow... thanks!

<p​lowsof:matrix.org> venture4487: nvmitsmatrixdotorg has contacted you with that info

<v​enture:monero.social> resolved already :)

directly because of the bots DM? or did you not read it and discover the method yourself (also ok)

<v​enture:monero.social> the bots DM helped, didn't know the correct url (matrix.monero.social)

thank you for this trust pilot review :'))

<s​pirobel:kernal.eu> 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. reddit.com/r/Monero/comments/1dfj7rs/new_tools_added_to_moneroc<clipped message>

<s​pirobel:kernal.eu> 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)

<s​pirobel:kernal.eu> so while it is not a strict thumbs down from me, I think the CCS should only be approved if he changes his behavior.

<s​pirobel:kernal.eu> Okay I just gave him a thumbs down. Because he seems to think this is funny and he does not take it seriously.

<s​pirobel:kernal.eu> matrix.monero.social/_matrix/media/…/kernal.eu/KNHIQarJCZfgvxxNJpxnrpgQ

<s​pirobel:kernal.eu> I took a look at the CCS proposal from back in the day. First he spells the name correctly.

<s​pirobel:kernal.eu> matrix.monero.social/_matrix/media/…/kernal.eu/HhbwMDhmwvxUixEzjQgOqJed

<s​pirobel:kernal.eu> and then he intentionally spells it wrong in an insulting way.

<s​pirobel:kernal.eu> matrix.monero.social/_matrix/media/…/kernal.eu/OXfvkeCaeSkUWFGoJmIqOmYx

<s​pirobel:kernal.eu> 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)

<r​ottenwheel:kernal.eu> dayssincelastdramainmonerocommunitygrouponmatrixorirc.xyz

<s​pirobel:kernal.eu> x.com/spirobel/status/1591350820708442112

<s​pirobel:kernal.eu> 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. reddit.com/r/Monero/comments/1dfj7rs/new\_tools\_added\_to\_mon<clipped message>

<s​pirobel:kernal.eu> 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)

<p​reland:monero.social> I would like to introduce to you the “afk compiler” theory

<p​reland:monero.social> 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

<p​reland:monero.social> 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

<p​reland:monero.social> 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<clipped message>

<p​reland:monero.social> 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.

<p​reland:monero.social> Tl;dr “shut up and code” isn’t the answer, the answer is “shut up OR code”

<s​yntheticbird:monero.social> wow excellent speech 👌

<p​reland:monero.social> Lol

<v​enture:monero.social> straight out of westworld 🤣

<r​ucknium:monero.social> Has anyone tried to use the new `subtractfeefrom` with `monero-wallet-rpc`? monero-project/monero #8861 . I've tried to get it to work, with no success. And the RPC docs aren't updated yet.

hm

does the example help Rucknium monero-project/monero-site #2249/files

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> But your proposed docs say that the -rpc input should be an array of ints.

<j​effro256:monero.social> Yes

<j​effro256:monero.social> Lmk how usability is

nice, does rpc support "all" also?

<j​effro256:monero.social> Nope

<j​effro256:monero.social> If it is desired, we could make the array [-1] mean "all"

we're lazy so -1 would stop us from learning what it means

<r​ucknium:monero.social> Wow it worked.

i cant believe you didnt check the un merged pull requests docs

<r​ucknium:monero.social> 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.

(a joke, should be merged already and live, sorry)

<r​ucknium:monero.social> If the docs get updated, that would be enough.

a powerful rpc call that should be part of every stressnet users arsenal

thank you jeffro256

<r​ucknium:monero.social> 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`.

<r​ucknium:monero.social> Yes this is for stressnet lol

<r​ucknium:monero.social> I thought I'd be clever and use this new feature :)

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?

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> vthor: Another possible problem I thought of: Insufficient entropy on wallet generation can allow thieves to steal from even airgapped wallets.

<r​ucknium:monero.social> Thanks for following up with jeffro :)

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'

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)

I do usualy what I'm saying. I'm only some time too busy to do it directly.

<r​ucknium:monero.social> Sounds good to me. Of course, the Monero seed words are different from bitcoin seed words. You just need to convert things correctly.

<r​ecanman:kernal.eu> vthor monero-python and monerophp have pretty straightforward implementations of generating monero seeds and encoding/decoding

And was still searching how to contact jeffro256....

<j​effro256:monero.social> That was my thought exactly

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

<j​effro256:monero.social> @vthor: hi! Yeah I'd be down to chat about it. I won't claim that I can enumerate all possible failure points though..

<r​ecanman:kernal.eu> Looks good vthor

<r​ecanman:kernal.eu> Your source of entropy is the camera?

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

in case of dices entropy comes from extern, but I wonder how many people will that actually do....

<r​ecanman:kernal.eu> Just wondering, why not /dev/urandom?

on the pi?

<s​trawberry:monero.social> reminds me of some bitcoin hardware wallet that let you roll a dice hundreds of times for entropy

I could throw it additionally inside

strawberry: exactly that with dices.

<s​trawberry:monero.social> and they had a python script to reproduce the seed from the rolls, to prove the firmware isnt evil

<r​ecanman:kernal.eu> I would recommend that vthor, I'm not sure if you're getting sensor data from the camera or the normalized image itself

yes, is the same method (seedsigner), its only a modification from btc to xmr strawberry

<j​effro256:monero.social> You should include /dev/urandom. It's usually a bad idea idea to rely on one source of unproved randomness

<r​ecanman:kernal.eu> security.stackexchange.com/question…ing-a-smartphone-camera-a-good-idea

recanman: would need to check again, how it is done.

<s​trawberry:monero.social> oh im blind, this already works with dices?

yes

<r​ecanman:kernal.eu> I concur with jeffro, urandom is 'proven' as it is used as cryptographically-secure source of entropy

<s​trawberry:monero.social> realistically the camera data is fine, but reproducible with dice rolls is good for paranoid users

<j​effro256:monero.social> This answer gets into why just using a camera can fail: security.stackexchange.com/question…hone-camera-a-good-idea/42430#42430

<s​trawberry:monero.social> is this meant to run on a pi? haven't been following

<j​effro256:monero.social> 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

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?

<r​ucknium:monero.social> So the original bitcoin seedsigner code isn't as good as it could be?

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.

<r​ecanman:kernal.eu> I would think that a proven source of entropy be used as a minimum

<j​effro256:monero.social> @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<clipped message>

<j​effro256:monero.social> y won't make things worse, and will help in most cases

<r​ecanman:kernal.eu> I would think that a proven source of entropy should be used as a minimum

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?

<r​ecanman:kernal.eu> If sha256 is a cryptographically secure hash function then the answer would be yes

<r​ecanman:kernal.eu> I'm not sure if it is considered one or not, just clarifying

In my last discousion with crytographers in #crypto and ##math they told me it is fine.

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

<j​effro256:monero.social> 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<clipped message>

<j​effro256:monero.social> 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

there is btw the linux emulator executable github.com/DiosDelRayo/MoneroSigner…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.

<j​effro256:monero.social> Some paranoid users may also not like that the camera could capture their face accidentally

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....

<j​effro256:monero.social> Who would do which part ?

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)

<j​effro256:monero.social> 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

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....

<j​effro256:monero.social> That's what the numpad would be for

<j​effro256:monero.social> People who want to roll dice can enter 1-6

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)

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.

<j​effro256:monero.social> That's what the hardware random number generator is for: true randomness based on provably random physical phenomenon

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.

<j​effro256:monero.social> 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<clipped message>

<j​effro256:monero.social> 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?

<r​ucknium:monero.social> 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.

<j​effro256:monero.social> Fair enough

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.

rucknium, thank you for the translation :)

<r​ecanman:kernal.eu> 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

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....

recanman: ack, I think that how it will be done, if there are no other concerns about.

<r​ecanman:kernal.eu> Sounds good vthor

forgot to paste bcm2708-rng

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.

<j​effro256:monero.social> 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

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?

<r​ecanman:kernal.eu> First one

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.

what are e-notes and key images?

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.

recanman, thought so :(

<j​effro256:monero.social> 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<clipped message>

<j​effro256:monero.social> 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

<j​effro256:monero.social> For your first cycle, you might want to not worry about multisig ;)

<j​effro256:monero.social> FCMP+SA+L makes all this significantly easier since we don't have to sync partial key images

okay :)

is there somewhere a log for this room?

<s​yntheticbird:monero.social> monerologs.net #monero-community

never mind, copied it in a text file. :)

<j​effro256:monero.social> 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

thank you syntheticbird :)

<j​effro256:monero.social> You will need to send key images from the cold wallet to the hot wallet to calculate your balance regardless of multisig

<j​effro256:monero.social> the private view key can only see incoming e-notes, not outgoign

the view key is not enough?

right

<j​effro256:monero.social> Sadly, no

<j​effro256:monero.social> The view-balance key will be enough once FCMP+SA+L and Jamtis are deployed

<j​effro256:monero.social> But until then, there needs to be 2 way communication between the cold and hot wallets to accurately display balance

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' :/

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 :/

<r​ecanman:kernal.eu> great to hear that partial key images don't need to be synced jeffro256, that really makes multisig so much easier

<r​ecanman:kernal.eu> (with fcmp)

<j​effro256:monero.social> 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<clipped message>

<j​effro256:monero.social> 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

<j​effro256:monero.social> 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

This functionallity exists on the monero-cli/gui side, right? On the monero-python side I will need to solve that, correct?

<j​effro256:monero.social> That I don't know... I will need to check if the monero CLI / GUI supports this

Do you know any software supporting it today?

<j​effro256:monero.social> I know `wallet2` supports it, but hopefully something higher level than that also does...

where is wallet2 to find? is that a lib?

<j​effro256:monero.social> Here's the commands for `monero-wallet-cli`: docs.monero.study/interacting/monero-wallet-cli-reference/#key-images

<j​effro256:monero.social> `export_key_images <file>` and `import_key_images <file>`

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

<j​effro256:monero.social> yes private key view. If you see something that only says "view key", it's the private view key.

<j​effro256:monero.social> the private view key is derived from the private spend key, except in multisig wallets and really really old wallets

<j​effro256:monero.social> but when you export a view only wallet, you don't get the private spend key

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...)

Okay, it seems I will have some 1-2 lab days :D I head is smoking now.

<j​effro256:monero.social> don't worry about partial key images unless you're doing multisig

<j​effro256:monero.social> You just need to worry about normal/full key images for single singer wallets

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.?

<j​effro256:monero.social> key images are associated 1-to-1 with e-notes (transaction outputs)

<j​effro256:monero.social> Yep that's fine !

<j​effro256:monero.social> Monero has a very steep learning curve for everyone when building infrastructure, so don't fret ;)

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)

Have a great one everybody and thanks for the patience with me :)

<j​effro256:monero.social> Best of luck with MoneroSigner! I'll probably be lurking in these chat rooms if you need anything, just lmk

<r​ucknium:monero.social> jeffro256: Did you test the `subtractfeefrom` with 16-output txs?

<r​ucknium:monero.social> 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

<j​effro256:monero.social> What's probably happening is that a change output is getting inserted in there somewhere

<r​ucknium:monero.social> 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)

<j​effro256:monero.social> 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

<j​effro256:monero.social> Oh okay weird

<j​effro256:monero.social> I will check it out

<r​ucknium:monero.social> I am not 100% sure. Maybe 75% sure.

"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 ..."

<m​ultix:frei.chat> 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.

As far as I know, no. There are simply too many public nodes that work for free

<r​ucknium:monero.social> multix: AFAIK, pay-for-RPC is being deprecated.

<s​trawberry:monero.social> really? was it ever used in practice?

<s​trawberry:monero.social> 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

<s​trawberry:monero.social> 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

<p​lowsof:matrix.org> multix F monero-project/monero #9248

<r​ucknium:monero.social> 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?

<j​effro256:monero.social> 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

<s​trawberry:monero.social> On second thought RPC payments do seem fairly useless, since it only takes 1 free node to be online for everyone to stop paying

<s​trawberry:monero.social> In the case of an attack, chances are that 1 free node is a spy node

<s​trawberry:monero.social> Albeit RPC payments never make the spy node problem worse, since the paid nodes would just shutdown

<j​effro256:monero.social> Good point. But depends on whether people know the spy node is a spy node or not

<s​trawberry:monero.social> true, people might pay a premium to a "trusted" rpc provider, but those people are the same type to run their own nodes

<j​effro256:monero.social> Also an argument for more resilient wallet-daemon information protocols in general

<m​ultix:frei.chat> plowsof: Rucknium huh, thats unfortunate, thanks for the info.

<c​t:xmr.mx> 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.

<c​t:xmr.mx> True randomness sources would of course be even better, but it might be out of scope for the CCS

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

firewalls. Help, what's wrong with installing P2Pool? Windows version 7 is professional. The node is fully synchronized (full node). ;(