00:36:02 don't be evil vs can't be evil 00:53:40 I think the priority of many implementers is complying with the protocol. Rather than fingerprinting on purpose, it's just a matter of putting something together that works. If 'what works' reduces the possibilities to fingerprint, that's progress in my book. Fingerprinting should be a very intentional process, instead of the default. 00:55:41 Maybe I'm missing something here, but it should work out of the box. If they added some custom data, it's because they actually worked to do it. 01:16:21 there is some possibility of some custom data that might not be fingerprintable 01:16:50 so in that sense i would tend to agree that making it easy to avoid unnecessary fingerprinting could be helpful 01:18:08 in a lot of cases, though, extra data is going to be a fingerprint period, and making it easi to include on chain is inviting it 01:18:10 Yes, but that would be taken care of by making the format that but not enforcing it. 01:18:36 i dont really know how you do that besides enforcing 01:19:19 Prevent fingerprinting ? Remove extra I guess. Put tx keys and other things we need in strict fields. 01:19:23 isn't it the same as sorting keys. if everyone just did it, you wouldn't have to enforce, but demonstrated that some wont, not for any particular reason 01:20:09 I think it's not the same: that's something you have to have. People don't have to have custom extra data, and yet some added it. 01:20:25 sorting vs. not sorting is the same imo 01:20:34 That fingerprints in itsel, whether in a format or another. 01:20:59 the point being that it is easy to sort, but you can't really get people to sort without enforving 01:21:14 enforcing is basically how you coordinate 01:22:00 I get that. But if you enforce a particular framing for extra, the custom data is still there, that framing format did not get rid of the fingerprint, whereas enforcing sorting did. 01:22:37 some custom data is not going to be a fingerprint 01:23:27 but it could unnecessarily become one due to custom framing 01:23:39 I either do not agree or do not understand your point. 01:23:49 The main point for me is that NON-custom data will no longer be fingerprintable 01:24:01 is it now? 01:24:49 Yes, the sorting vs nonsorting distinction for normal tx, and the random implementation of extra nonce for pools (which I consider non-custom since all pools use the extra nonce). 01:25:00 moneromooo: lets say the custom data is an encrypted message. there is nothing fingerprintable about that, it is just random data 01:25:16 The fact that your tx includes this field is the fingerprint. 01:25:30 it could be, depends how widely used 01:26:18 Then a bettr thing to do it add a "custom data encrypted with the receiver key" field, whether or not the framing changes. 01:26:41 i think you are basically saying get rid of tx extra 01:26:46 So all people who want to include an opaque blob can use that (though there is still a question of message length). 01:26:56 This is essentially the Zcash "encrypted memo" 01:27:06 which is a fixed 512-byte blob that's required 01:27:16 if the max is short enough you could make it fixed length 01:27:30 pretty much what we do with payment id 01:27:33 I was planning on quantizing to mutliple of N bytes. 01:28:07 that's still "anonymity puddles" in Isthmus's language 01:28:22 you want every multiple of N to be either widely used or not at all 01:28:25 Yes, but it's better, and there's no perfect here. 01:28:41 so that pretty much means a small cap in practice, maybe not N*1 but N*some small integer 01:29:06 True. Then maybe well known sizes, like 0, 32, 256, 4096. 01:29:10 (examples) 01:29:53 512 bytes per tx seems a bit heavy. It does away with the puddles though, so it's tempting. 01:30:01 thats plausible 01:30:02 This would be in addition to separating out key fields? 01:30:12 so truly arbitrary data? 01:30:15 might get rid of 0 01:30:30 In my mind, it'd be a new extra field, yes. Independent of any others. 01:31:50 I think that's a much better idea 01:31:59 still not enforceable to be actually encrypted, of course 01:32:52 You could make the fee inversely proportional to the exponential of its entropy 01:34:12 im not really sure how we got to this point. the earlier discussion was about reducing fingerprinting, and we just added another one, although hopefully done in a way that minimizes the fingerprint. but it is still one 01:35:21 *confused as well* 01:37:50 Well, either there's room for some kind of arbitrary-ish data, or there isn't 01:37:57 moneromooo: would you mind adding your proposal to the git issue on this topic? 01:38:22 I think there is one already. Old. 01:38:47 But as smooth said it's really a different thing. 01:39:00 Can you add a reference/link? It seems like a counter proposal 01:39:13 Is the underlying question whether having _any_ allowances for arbitrary data is a good idea? 01:39:32 (beyond required fields and pID) 01:39:51 It's more about the scope of the protocol 01:40:28 It is certainly related. I've always been in favour of allowing it, but we've not seen any stupendous use so far, and the ones I've seen are more spam than innovative :( 01:40:44 So I'm slowly losing my support for it I think. 01:41:29 Nixing arbitrary extra in favor of fixed fields makes me happy from a protocol perspective, but who knows what applciations would break 01:42:31 I think killing the extra field presupposes indefinite hard forks, which is an unrealistic assumption 01:42:45 i dont think thats the case 01:44:26 Doesn't seem to be an issue about it, I only found https://github.com/monero-project/monero/issues/1518 which is related but not that. 01:44:38 Or "Extra" did not grep it anyway. 01:45:18 Well if improvements to the protocol slow down, which is reasonable as there are diminishing returns, then hard forks will become more spread out. As adoption rises, coordinating those hard forks will also become harder. At some point they will probably become infeasible for anything except groundbreaking improvements. 01:46:06 They are also useful for client software upgrades 01:46:21 Protocol requirements are a good incentive to upgrade your software :) 02:08:55 How much adoption can be sustained by the core team? I feel like either Monero will grow beyond the primary implementation, at which point questions of 'default configuration' for non-protocol features like the extra field will be out of control (I agree with moneromooo that if implementers just take what core team ships, then fingerprinting is caused by 'messing with it'; of course, this falls apart if a project 02:08:55 tries to maintain itself without constantly rebasing, for example I'm guessing the existence of non-sorting extra fields is an implementation that forked BEFORE the core implementation started sorting, and they just didn't realize the field should be sorted now [a plausible explanation, other teams can't be expected to keep up with everything the core team does]), or the dominance of that implementation will lead to 02:08:55 an upper limit on infrastructure growth. 02:10:36 My proposal is especially to prepare for a future where core team has less influence. Now is the time to tie down loose ends. 02:25:54 Question, I want to make a test that makes it where connecting nodes reject blocks that do not accept the full block reward. Do i have to change the block template? 02:50:11 or do i have the change the base_reward in the cryptonote_basic_impl file? 06:00:08 https://www.getmonero.org/resources/developer-guides/wallet-rpc.html#set_account_tag_description says both inputs for describe_transfer are optional, but calling it without without params: {:error {:code -1 :message "no txset provided"} :id 0 :jsonrpc "2.0"} 15:33:00 so I was thinking earlier today, in custodial[-like] cases where a site has multiple users and ultimately each user is assigned its own wallet on the server (and get their address books, accounts, etc as a result), wouldn't it make sense to add 2FA support to the api? this way monero-wallet-rpc would work as a last line of defense by refusing to make transfers without being presented with a valid auth token. it would be completely optional 16:46:13 would it be opt in or opt out in terms of being optional 16:53:22 My testnet node is now running vtnerd 's Dandelion++ code - see https://github.com/monero-project/monero/pull/6314 16:54:00 I just don't know how much sense that makes, given the current very, very small size of testnet: My daemon is currently connected to only 4 other nodes 16:54:50 And how can I watch whether Dandelion++ does or does not do its magic? A quick glance over the code did not show me a new log category that would give info 16:55:46 Normal, "downward-compatible" tx propagation seems to work, at least did for a test tx between two of my own daemons 16:58:35 Insight: as I imagine it, opt in 16:59:23 just throwing the idea out there, i don't have the c++ skills to make it happen. if someone finds the idea interesting, that'd be a good addition imo