<k​eyur279:matrix.org> Working on Monero hardware wallet integration. Should bulletproofs be generated on the secure device or can the host generate them? If host generates bulletproofs using commitments and blinding factors from the device, does providing the masks compromise privacy?

<k​eyur279:matrix.org> What's the recommended approach from all the pros in community?

<j​effro256:monero.social> Do you care if the host devices knows the output amounts of that transaction ?

<k​eyur279:matrix.org> Personally I won't care if host knows the output (also I am new to monero), but my question is more about what's considered acceptable for hardware wallet implementations in general, just want to make sure I'm following community best practices.

<k​eyur279:matrix.org> Personally I won't care if host knows the output (also I am new to monero so might be wrong here), but my question is more about what's considered acceptable for hardware wallet implementations in general, just want to make sure I'm following community best practices.

<j​effro256:monero.social> Then you can do them on the host device. In most use cases, basically the only difference between doing the BPs on-device versus not is that the host can *verifiably* prove to a third-party that some amount commitmernt is committed to a certain amount

<k​eyur279:matrix.org> Thanks sire

Hi. I'm building a Monero block explorer. Are there any special security best practices recommended for doing this properly? Thanks.

It will be a public web explorer.

<s​yntheticbird:monero.social> WTF

<s​yntheticbird:monero.social> sgp_:

<s​yntheticbird:monero.social> there is a new "wanna build an explorer" virus propagating

what?

<s​yntheticbird:monero.social> You are the second person today building a new monero block explorer

<s​yntheticbird:monero.social> and there was a new one like 3 weeks ago

<v​tnerd:monero.social> Lol is this a good time to mention I want to build a TUI block explorer. Why not

<s​yntheticbird:monero.social> epic

Well man, monero marketcap grew 190% this yeat, what you were expecting? There will be blogs, explorers, etc..

<s​gp_:monero.social> For those out of the loop: github.com/MAGICGrants/rust-monero-explorer

<s​gp_:monero.social> It's MIT so feel free to have at it

<s​yntheticbird:monero.social> m​NeverHere ofc we support your endeavor, there aren't any security practices regarding the explorer tbh. Just make sure to keep your monero node private to avoid DoS

<o​frnxmr:xmr.mx> someone needs to build one for fcmp

<o​frnxmr:xmr.mx> testnets are no fun w/o explorers

<j​effro256:monero.social> Sometime soon I hope to modify the onion-blockchain-explorer

<j​effro256:monero.social> For the user, you really just get of rings ig right?

<s​yntheticbird:monero.social> Sometime soon i'll make a fancy blockchain explorer with gambling in it and web assembly mandatory

<j​effro256:monero.social> *get rid of

<j​effro256:monero.social> Regarding Carrot, would it be a good idea to show the view tag (3 bytes) and encrypted janus anchor (16 bytes) ? I can't really imagine what possible use that would have for a blockchain viewer...

<j​effro256:monero.social> But the current view tag is shown per output, so....

<j​effro256:monero.social> I also don't really know why. Maybe just to differentiate it from non-view-tag outputs?

<j​effro256:monero.social> I guess that by that logic it's not even worth showing stealth addresses anymore since rings don't reference them. Maybe it would be if you could map stealth addresses to key images in your wallet software ? I think the blockchain explorer is going to be really, really boring after FCMP++ lol

<o​frnxmr:xmr.mx> More info the better imo, behind flags perhaps

<s​yntheticbird:monero.social> That's good news i might say

spirobel: you mean due to block sizes varying, or more ?

(ie, is it still non deterministic with the same input ?)

(assuming non malicious node)

The reason for this was to "balance" the load, to avoid monster responses as the chain got busy. No other reason.

<s​pirobel:kernal.eu> because of the max response size in combination with varying block size will lead to variable amount of blocks

<s​pirobel:kernal.eu> the structure of the wallet libraries ask for blocks as the unit to scan on

<s​pirobel:kernal.eu> (unknowable amount of blocks is more precise than saying non deterministic)

<s​pirobel:kernal.eu> replacing the max response size in mb with in amount of blocks makes is more tenable

<s​pirobel:kernal.eu> replacing the max response size in mb with in amount of blocks makes it more tenable