-
br-m
<spyce.:zano.org> Yo, new to understanding the privacy and core tech in general.
-
br-m
<spyce.:zano.org> Does the idea that selfish mining becomes profitable once controlling over 1/3 of the hash rate stem from a pool's ability to decide to secretly branch off the chain (essentially creating their own private blockchain, for the time being) which would consequently cause the public network to reweight mining difficulty of procedi [... too long, see
mrelay.p2pool.observer/e/-cf0270KcmNqWml3 ]
-
br-m
<spyce.:zano.org> Obviously there's some nuance to this due to statistics/probability but the main gist is that it theoretically becomes sustainable once over 1/3 right?
-
br-m
<hbs:matrix.org> Regarding the incoming view key, I understand your point @sgp_:monero.social is that the way they work they can allow the determination with a high confidence of the actual spend. But if I understand the benefit of FCMP++, this wouldn't be the case once it's out, because we're done with the current ring signatures. Am I correc [... too long, see
mrelay.p2pool.observer/e/mNOW3L0KUWtjZTVp ]
-
br-m
<testtank:matrix.org> But you can’t be pressured into sharing it, if it doesn’t exist > <@sgp_> The key whose exact purpose is to share your transaction history does in fact do that, yes. I see 0 issues with this. If you don't want to share your info, simply don't share the key
-
br-m
<sgp_> @testtank:matrix.org: Your private spend key exists...
-
br-m
<monero.arbo:matrix.org> if someone's threat model requires this, I would suggest to that person to routinely delete and create new wallets rather than counting on whatever jurisdiction going "ah well, there's no view key, we've been foiled"
-
br-m
<testtank:matrix.org> I’m not a laywer, but i would think it’s easier for a judge to sign off on a warrant to force you to give up the view key rather then the spend one, i agree that it should be opt-in
-
br-m
<monero.arbo:matrix.org> I'm not sure that designing Monero around some theoretical legal standards makes a lot of sense anyway
-
tevador
You can just as easily be forced to give up the incoming view key and all key images, which is equivalent to the outgoing view key.
-
br-m
<hbs:matrix.org> tevador: At given time yes, the view balance key is forever
-
br-m
<monero.arbo:matrix.org> Can you explain functionally the difference between those two scenarios? it seems to me that in either case, the wallet is compromised and should not be used any more
-
br-m
<hbs:matrix.org> @sgp_: But turning this one on opens a totally different legal matter as it gives actual ownership of the wallet
-
br-m
<monero.arbo:matrix.org> well no, the private key doesn't give legal ownerhsip, if we are talking about laws and legal systems
-
br-m
<monero.arbo:matrix.org> which, afaict nobody here is any kind of legal expert and is just guessing
-
br-m
<hbs:matrix.org> @monero.arbo:matrix.org: It does as it allows the wallet UTXOs to be transferred
-
br-m
<monero.arbo:matrix.org> that's not legal ownership that's theft
-
br-m
<hbs:matrix.org> But you are right, control is more appropriate than ownership
-
tevador
You can be required to report the key image for all future incoming payments. If not, jail time.
-
br-m
<hbs:matrix.org> tevador: Sure, but this is not a valid reason for having view balance keys by default
-
br-m
<monero.arbo:matrix.org> I think it's a neat option if it's as easy as suggested (would still like to hear confirmation of this) but I personally don't see the loss in UX as worth it for the typical user
-
br-m
<monero.arbo:matrix.org> the "reason" is it's a useful feature
-
br-m
<hbs:matrix.org> @monero.arbo:matrix.org: That's the same narrative used by Ledger to justify their ledger recover feature is in all firmwares
-
br-m
<monero.arbo:matrix.org> turns out, different things are different
-
br-m
<monero.arbo:matrix.org> news at 11, etc
-
br-m
<monerobull:matrix.org> is stressnet V2 already live?
-
br-m
<hbs:matrix.org> I still haven't read any argument as to why NOT having a view balance key by default is an issue, letting those who want one have one
-
br-m
<dgently:catgirl.cloud> @hbs:matrix.org: I was about to write something similar
-
plowsof
step 1: dilute the discussion over many rooms. step 2: invent the misnomer "auditable" vs "non auditable" step 3: claim no reasons have been provided (but redact 'that i see as being valid' or something
-
br-m
<syntheticbird> step 1: go in chat. step 2: read the chat. step 3: nuclear reaction
-
br-m
<monero.arbo:matrix.org> yeah I was about to say, arguments have absolutely been given and it's weird to pretend they haven't
-
br-m
<hbs:matrix.org> @monero.arbo:matrix.org: I haven't seen them, sorry, the discussion seemed to focus on the usefulness of the vb key, not on its default status.
-
br-m
<hbs:matrix.org> plowsof: Why do you call that a misnomer? What better name would you use?
-
br-m
<plowsof:matrix.org> a non auditable wallet can be audited
-
br-m
<hbs:matrix.org> @plowsof:matrix.org: Only at the time the owner decides (or is forced to), the view balance key allows to see indefinitely what comes and goes
-
br-m
<hbs:matrix.org> @plowsof:matrix.org: Ok I understand your misnaming consideration then, what other name would you suggest?
-
br-m
<monero.arbo:matrix.org> how is arguing that it's useful not an argument for default inclusion? people have also made arguments that the absence of a view key is unlikely to be helpful. > <@hbs:matrix.org> I haven't seen them, sorry, the discussion seemed to focus on the usefulness of the vb key, not on its default status.
-
br-m
<monero.arbo:matrix.org> for me the bottom line is that view keys are a widely existing and expected crypto feature that are not inherently compromising. the Monero privacy ethos has always been for keeping data off chain, and letting users choose what to share. having view keys by default fits this ethos without, as far as I can tell, substantively harming user privacy.
-
br-m
<monero.arbo:matrix.org> I would instead argue that the burden of proof, so to speak, is on you for why it's necessary to remove an exceedingly useful feature in the default wallet configuration. so far the arguments I've seen from you have depended on vague maybe laws that possibly exist in some jurisdictions, which is not concrete at all
-
br-m
<hbs:matrix.org> Suppose you get indicted, you need to hand your incoming view key + key images. You get condemned, but your assets are not seized. You serve time to pay your debt to society. Once this is settled, you decide to move your funds elsewhere, this is not something that will be trackable. On the contrary, you hand over your view bal [... too long, see
mrelay.p2pool.observer/e/l8en570KbHY3dnZR ]
-
br-m
<monero.arbo:matrix.org> If you're convicted, most if not all jurisdictions will require you to hand over the crypto keys as proceeds of crime. which sure, you could refuse, but you could just as well have refused to give away view keys to begin with
-
br-m
<monero.arbo:matrix.org> And genuinely, are you a lawyer? what jurisdiction are you talking about? Either way, I tend to think Monero should be making technical decisions, not choices that are made around laws that are different at different places at different times.
-
br-m
<boog900> > Once this is settled, you decide to move your funds elsewhere, this is not something that will be trackable
-
br-m
<boog900> they will see the key images being spent
-
br-m
<boog900> unless you only move funds that were received after you had to hand over all KIs
-
br-m
<hbs:matrix.org> @monero.arbo:matrix.org: Monero should make decision by considering diversity, not assuming that all jurisdiction function like the worse ones. If you read my writing carefully you would see that my main concern is not directly related to the actual defaulting to the existence of vb key or not but rather to the fact that b [... too long, see
mrelay.p2pool.observer/e/zarD570KMHRaNU9f ]
-
br-m
<dgently:catgirl.cloud> plowsof I am #1 as I posted in multiple rooms because my previous attempts to start a conversation did not happen
-
br-m
<dgently:catgirl.cloud> I posted in off-topic as there is often more engagement there, in monero as there was an ongoing convo and here as it seemed the most appropriate room
-
br-m
<dgently:catgirl.cloud> Please give me a choice. :)
-
nioc
Yes ^^ this is me
-
nioc
Supposed to be a read only account. I created it because I was losing context from matrix posts on irc
-
tevador
hbs:matrix.org: You have the option to move funds to a new wallet if your old wallet was compromised by law enforcement. I don't really see any arguments for not having an outgoing view key. For example, hardware wallets are a UX nightmare without OVKs.
-
br-m
<hbs:matrix.org> tevador: I am not saying to not have an outgoing view key, I am advocating for allowing the user to choose if they want to create a wallet with one or not (by setting s_vb to k_ps as suggested by @jeffro256).
-
br-m
<kayabanerve:matrix.org> Then you still have a view balance key. It just lets anyone who can view your balance also spend your coins.
-
br-m
<hbs:matrix.org> @kayabanerve:matrix.org: Excactly, that's what I wrote.
-
br-m
<kayabanerve:matrix.org> ... yes, so what's the point of making view balance keys worse?
-
br-m
<kayabanerve:matrix.org> You don't like it lets people view balances. Your proposed solution is to ALSO let them spend coins?
-
br-m
<hbs:matrix.org> Please read my proposal throughout, what I am advocating is for people to have a choice, what is wrong this that?
-
tevador
hbs:matrix.org: I'm not a lawyer, but I'd say the court will still ask you to hand over your s_ga, even if it's equal to k_ps. They can just pinky promise not to seize your coins until you are convicted.
-
br-m
<kayabanerve:matrix.org> I'm asking what sane person wants to give anyone access to view their coins also access to spend them.
-
br-m
<boog900> @kayabanerve:matrix.org: it "protects" against a situation where someone can force you to give up the view balance key without giving up the full spend key
-
br-m
<kayabanerve:matrix.org> And isn't that exact use-case solved by communicating the private spend key?
-
br-m
<kayabanerve:matrix.org> @boog900:monero.social: Except it doesn't. There's still a view balance key.
-
br-m
<hbs:matrix.org> tevador: This is very jurisdiction dependent, and it's not because some country will do this that it should be considered all would, or even have the legal ability to, do so.
-
br-m
<kayabanerve:matrix.org> It can still be communicated.
-
br-m
<kayabanerve:matrix.org> You're just the idiot who set it to your private spend key.
-
br-m
<boog900> @kayabanerve:matrix.org: they could be unable to get you to give that up as that gives spend ability
-
br-m
<hbs:matrix.org> @boog900: Which, in many jusrisdiction would go against the right to private property and would therefore be illegal
-
br-m
<boog900> FWIW I am just communicating the argument
-
br-m
<kayabanerve:matrix.org> Let's say there is a court of law which requires surrendering view keys. Just because you say
-
br-m
<kayabanerve:matrix.org> "Oh, but I set my view key to my spend key, oh ho ho"
-
br-m
<kayabanerve:matrix.org> That'll make you immune to giving up your view key?
-
br-m
<hbs:matrix.org> @kayabanerve:matrix.org: In many jusrisdictions yes.
-
br-m
<kayabanerve:matrix.org> @boog900:monero.social: No, there is a view balance key that lets you view the wallet.
-
br-m
<kayabanerve:matrix.org> The fact it's equivalent to the private spend key is just a distinct fact
-
br-m
<hbs:matrix.org> There would be a valid legal argument to oppose the requirement
-
br-m
<kayabanerve:matrix.org> We're discussing theoretical mitigations for a totalitarian society which passes a law forcing reporting of view keys with an explicit carve out for if they allow additionally allow spending, despite being a totalitarian society who wouldn't care for such legal "gotchas"?
-
br-m
<kayabanerve:matrix.org> @hbs:matrix.org: Name a single jurisdiction where reporting requirements are nullified if reporting happens to give spend authority away.
-
br-m
<ofrnxmr:xmr.mx> I dont think this is a hypothetical
-
tevador
In any case, the wallet key hierarchy is not enforced by consensus. so users can already do what you are asking (set s_ga = k_ps). They just need to write the code. So essentially, you are asking "please write me code to support feature X". This typically entails hiring someone.
-
br-m
<hbs:matrix.org> @kayabanerve:matrix.org: I didn't say it was nullified, I said you had a legal basis to oppose the requirement
-
br-m
<ofrnxmr:xmr.mx> @kayabanerve:matrix.org: Any where they dont have justificstion to seize property yet
-
br-m
<kayabanerve:matrix.org> Please, tell me how I can not report my bearer bonds to the IRS because by presenting them for reporting purposes, the IRS would hold them, and therefore I don't have to report them /s
-
br-m
<kayabanerve:matrix.org> @ofrnxmr:xmr.mx: It's funny how that doesn't name one
-
br-m
<hbs:matrix.org> @kayabanerve:matrix.org: This is a US centric example I am not qualified to answer.
-
br-m
<ofrnxmr:xmr.mx> @kayabanerve:matrix.org: USA
-
br-m
<kayabanerve:matrix.org> The USA doesn't require me to disclose my financial transactions if they'd gain spend authority?
-
br-m
<kayabanerve:matrix.org> I can have a foreign bank account, undisclosed, on argument reporting it would make the US aware of it and able to levy charges against it?
-
br-m
<boog900> they wouldn't be sizing property, you would still have the coins
-
br-m
<hbs:matrix.org> tevador: My argument was that making the vb key optional would lead to wallet providers including the option, whereas if you make it the default, then the option to remove it will probably not be implemented because of the perception it would trigger.
-
br-m
<ofrnxmr:xmr.mx> @boog900: id argue that posessing the spend keys is a seizure
-
br-m
<ofrnxmr:xmr.mx> Whereas the view keys is a search
-
br-m
<kayabanerve:matrix.org> Wow, do you charge for your services as accountant or...?
-
br-m
<kayabanerve:matrix.org> I mean, you're required to disclose transactions
-
br-m
<kayabanerve:matrix.org> And you made it so disclosure forces spend authority grant
-
br-m
<kayabanerve:matrix.org> And the law would need a carve out
-
br-m
<kayabanerve:matrix.org> It's a ridiculous hypothetical against a totalitarian government approaching sovereign citizenry
-
tevador
hbs:matrix.org: It doesn't negate anything I said. Your wallet software can have s_ga = k_ps by default. Someone else's wallet software can do something else.
-
br-m
<hbs:matrix.org> @kayabanerve:matrix.org: "the law" from which jurisdiction? I don't think you can reason with a specific law in mind, there are too many differences between countries
-
br-m
<kayabanerve:matrix.org> "The government is fascist, but if I sign my name in blue ink, this one legal gotcha will make them unable go act against me"
-
br-m
<kayabanerve:matrix.org> Anyways, the above comment re: this isn't consensus enforced and wallets can do whatever is the real one.
-
br-m
<hbs:matrix.org> tevador: My point is that presenting the OVK as an option makes it more likely to have wallet software implement the opt-in rather than the other way around where they could be reluctant to implement an opt-out. That's the chain of thought I detail in my document.
-
br-m
<gingeropolous> im sure some wallet software will set up some nice shadow accounting features. similar to the existing seed offset thing
-
nioc
Yes, but if what is proposed is default the wallet providers will have it and if not then probably not
-
nioc
Is having the option a bad thing?
-
nioc
Is having the option not implemented in many places a bad thing?
-
tevador
I think it would be OK to add a note to the Carrot specs that setting s_ga = k_ps will remove the outgoing view key functionality (and probably make you unable to use a hardware wallet).
-
br-m
<hbs:matrix.org> tevador: Why would not having an OVK make HW unusable?
-
tevador
Correction: I meant s_vb = k_ps. Since s_vb is needed for scanning for owned outputs, you would need to scan the blockchain on the hardware wallet, which is unlikely to be supported.
-
br-m
<hbs:matrix.org> tevador: Thanks for clarifying, makes sense.
-
br-m
<plowsof:matrix.org> jeffro256 can clarify the HWW situation - iirc the HWW does not have to scan the blockchain, rather, complete some less intensive task - or would this change depending on the OVK use or not i dont know
-
br-m
<kayabanerve:matrix.org> tevador: You may lose forward secrecy too.
-
br-m
<kayabanerve:matrix.org> You're removing a free variable from the equations, and F-S is premised on how the equations are under-determined.
-
br-m
<kayabanerve:matrix.org> I'd have to check of CARROT does still yield multiple, uniformly distributed variables even when keys are reused. Presumably, due to DSTd hashes? But ugh.
-
tevador
-
tevador
note*
-
br-m
<articmine> Which jurisdictions? > <@hbs:matrix.org> In many jusrisdictions yes.
-
nioc
My wallet my choice
-
br-m
<hbs:matrix.org> @articmine: in France you can contest if you have a legal basis to do so, and risking the relinquishing of the control of your coins is such a legal basis. If you have separate OVK this is not the case
-
br-m
<syntheticbird> @hbs:matrix.org: curious
-
br-m
<syntheticbird> I thought France had a strict key disclosure la
-
br-m
<hbs:matrix.org> @syntheticbird: For encryption yes, but the OVK seems to be outside the scope
-
br-m
<syntheticbird> OVK?
-
br-m
<hbs:matrix.org> Outgoing View Key
-
br-m
<boog900> this is such weak protection
-
br-m
<boog900> but at the same time I don't really care if OVK were opt-in