18:31:37 Rucknium or vtnerd couldn't we reject reorgs deeper than 10 blocks in all circumstances? 18:34:31 and (centralized) cant we also make use of dns-checkpoints? And have the checkpoints updated regularly by pulling from seed node's blocks 9-10 blocks deep? 18:34:33 Dns checkpoints are opt-in, so wouldn't fix a surprise attack. 18:34:48 Yes. That's exactly what BCH does today. But then to be sure that you are on the "correct" chain, your node has to stay online at all times. If you don't stay online, then you could come back and there could be multiple chains surviving, on a bifurcated network. 18:36:18 Today, a Monero CLI or RPC wallet will reject a re-org deeper than X blocks. I don't remember what the depth is. You would have to manually set the acceptable reorg depth on those wallets if there is ever a re-org deeper than X. 18:38:07 Maybe it's true with the GUI wallet and all wallet2-based wallets. I'm not sure. In that situation, I think the wallet is basically stuck if you don't change the max reorg depth, since the node (that the wallet is connected to) will switch chains 18:38:18 I learned this from Townforge :D 18:56:20 https://stackoverflow.com/questions/67907972/monero-wallet-rpc-keeps-saying-set-max-reorg-depth-n-no-matter-what-i-do 18:57:35 If you type `set` into your `monero-wallet-cli` console, it will show the wallet config. The default value for `m_max_reorg_depth` is 100. 20:20:34 I would like to open a discussion regarding the view-balance key introduced by CARROT. 20:20:35 The goal of the view-balance key is to allow a third party to be able to compute a wallet's balance without having the possibility to spend any of the funds held in this wallet. This possibility is an extension of the view key concept existing in the current Monero implementation and is a great addition for many scenarios where a wallet owner may want (or have) to make the balance 20:20:37 and outgoing transactions viewable by others. 20:20:39 The view-balance secret (s_vb) coexists with an incoming view key (k_v) which allows identification of incoming enotes as in the current Monero implementation. 20:20:41 The current CARROT proposal defines those keys for all newly created wallets. This implies that the view-balance secret s_vb will be available for all wallets and may therefore become a piece of information highly sought after by actors wishing to peek at transactions coming in and out of wallets. Some actors, or even regulations could require that this piece of information be rev 20:20:43 ealed hence jeopardizing the privacy aspects of Monero we all value. 20:20:45 Proponents of the view-balance secret often explain that the existing view key already allows to identify spent outputs with a "high probability" and that therefore the introduction of the view-balance secret doesn't change the expected privacy. They also argue that a user could be forced to provide key images and therefore that there is no guarantee of privacy. 20:20:47 The difference with the current situation is that a "high probability" is not a "100% probability" and this difference, however tiny, may be decisive in a court case, at least in many jurisdictions. As for the key images, indeed a user could be compelled to reveal them or face further charges, but the decision would be his (or hers). The introduction of the view-balance secret cha 20:20:49 nges this situation completely since the revealing of it gives access to the current balance and all future balances of the wallet, whereas providing key images is only doing so if systematically done for all future outputs, which, again, would probably be something difficult to obtain in many jurisdictions. 20:20:51 This is a point I raised concerns about earlier this year in the Monero Policy Workgroup (https://matrix.to/#/!aFGXKcPvUExSWMkVYu:matrix.org/$plHhR1-0mDiifpGDnCNqYviVtmgFQ2R4TGShL8c2c9c). jeffro256 replied very interestingly with the possibility to set s_vb to k_ps (the prove spend key which allows to spend the enotes of the wallet) which would make the revealing of s_vb actually 20:20:53 equivalent to giving full access to the wallet. 20:36:41 As my post may be too large for bridges and relays to handle it correctly, here is a link to it on a GitHub repo: https://github.com/hbs/MoneroMisc/blob/master/CARROT-discussion.md 20:41:07 I think we should have something like this for nodes 20:44:32 I think it would make sense for both nodes & wallets to be set to max reorg depth no greater than the block-lock, but maybe there's reasoning against that idea 21:09:15 I think I explained the downside here ^ 21:09:56 And it's against this principle stated in the bitcoin white paper: 21:09:57 > Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone. 21:11:12 But Satoshi was wrong about the desirability of nodes following the _longest_ chain. Notes should follow the chain with the most PoW. So maybe this principle can be ignored because Satoshi wasn't right about everything! 21:13:27 I'm not necessarily against changing rules to a rolling block checkpoint. Anyway, doing that doesn't stop a 51% attack. And if an adversary consistently has enough hashpower to feasibly re-org more than 10 blocks, then it probably has more than 50% of hashpower anyway. 21:27:08 Sounds like its backwards to add to wallets but not nodes. Whatever node i connect to should be inline with my wallet. If all nodes reorged 300blocks, then my wallet setting of 100 (or 10, or whatever l set to) is purely cosmetic / historical / archival 21:30:01 nodes could reorg to be on the highest pow chain within 10 blocks. Wouldnt this make all nodes stay in sync to within the 10 block lock (so not possible to revoke spent coins). Meaning wallets should always be connecting to a node that is on the "real" chain, since it could only reorg 10 blocks as well 21:31:16 Yeah but if it was 10 blocks max, then they can mine empty blocks / censor tramsactions, but they cant revoke fully unlocked outputs 21:31:50 If they tried to reorg greater than 10 blocks, the rest of the network would reject them and their chain 21:33:55 Remember on stressnet, i "stole" your chain and reeorged like 1000+ blocks while mining empty blocks iirc. This wouldnt be possible if peer nodes rejected my alt chain very-deep,secretly mined alt chain 21:36:09 I just think that anything above 10 blocks doesnt make sense, and that wallet having this setting doesnt help because nodes decide what chain is correct. Setting should be on nodes and is nice-to-have-but-not-necessary on wallets. 21:37:52 <3​21bob321:monero.social> So for an example an exchange can require it to transfer out ? Cause the code allows it? 21:47:15 It's the rest of the network, except for nodes that are offline (or who have yet to be born.) When the offline nodes come back, and new nodes sync from scratch, there are two chains. And possibly the attacking chain has more PoW. How do the offline or new nodes know what happened, and which chain is the "true" one? 21:49:24 I don't know why wallets have that max-reorg-depth, but it could be to defend against malicious remote nodes. 21:49:25 getting forked off like that is already an issue, isnt it? 21:50:40 You only needed to steal my chain, with deliberate effort, when the stressnet wasn't syncing together properly because of bugs 21:50:50 Yeah. I assume so, which is why its a nice-to-have, (malicious node cant delete your wallet history if it can only go back in time 1/7th of a day) 21:51:52 Because of bugs can lead to the same result as because of 51% attack stealth mining 100s of blocks 21:52:45 Lets play devils advocate and say someone has been stealth mining for 3 days now with 10gh. Currently they can reorg the whole network iiuc 21:52:55 We shouldn't have been split like that in the first place. And even if somehow that did happen without bugs, the collapse into one chain should have happened naturally when the two split networks started to talk to one another. 21:53:53 Resulting in revoked transactions, since their stealth mining wouldnt have seen the txpool in that time 21:54:19 And after 3 days txs are dropped from txpool anyway, so sending them back to txpool would lead to them being dropped (again, iiuc) 21:55:05 Having 10 block rolling would prevent any of the network from revoking transactions, and make stealth mining only an attack against offline or new nodes who were trusting the longest kr highest pow 21:56:26 I have no disagreement with your logic. 21:59:59 We have had issues with nodes getting sybilled and stuck during initial sync due to malicious nodes at a certain height sending garbage blocks, the workaround being using `--add-exclusive-node` to get past the sybil. Probably the dns checkpointing or seed nodes could be used as an authority when encountering altchains 22:00:05 wasn't any "cutoff at N blocks" logic vulnerable to network split attacks, if an attacker releases an alternative chain of exactly N blocks? 22:01:05 but exactly N blocks at 10 wouldnt be very useful since xmr isnt spendable for 10 blocks, is my line of thinking 22:03:24 yes, but splitting the network is an attack anyway 22:04:55 i would (personally, idk if it makes sense network wide) want my node to ban any peers who try to reorg by > 3 blocks 22:06:38 then the attacker reorgs half of the network by 2 blocks, and both halves mine their own 3rd blocks and ban each other 22:09:22 Hm