03:10:39 I see many YouTube channels posting Monero addresses in video descriptions to solicit donations. Most of those people cannot "self host a service that provides new addresses for each donor" when the address is put in a video description. However, I can see this being a new address type that exists alongside normal addresses. 04:48:27 What do you mean with a new address type? each donation already creates an ephemeral destination due to how monero works 05:45:37 Wouldn't the interactive part limit use cases? How would it work on a POS? How would services which generate addresses work? 05:58:04 Was reminded of this (with regards to static donation addresses): https://www.fsf.org/news/free-software-foundation-receives-historic-private-donations 05:58:50 Just to be clear, this is unrelated to hbs' comment 06:33:02 @torir:unredacted.org: I think they would be better served if they were to sign up to xmrchat. We get more durable network effects and they get a direct relationship with their audience that youtube can't cut. Plus they can be discovered through the xmrchat creator list. Three things: 1. why is there currently no way to di [... too long, see https://mrelay.p2pool.observer/e/z8O7kYYLU0ZhTFBH ] 06:39:46 hbs: they work just like checkout pages work now. for POS this can be transparent to the user. the wallet can just communicate with the pos terminal via a rest api. but in this case it wouldn't even be necessary. if the wallet app is opened to scan the qr, it is unlikely that there will be eavesdroppers, so the qr code can contain the freshly generated psk. 06:40:51 and all that observers would know is that somebody paid. but they just observed the shopper in front of the counter 06:51:10 @spirobel:kernal.eu: I understand that the lack of potential eavesdroppers is what makes it possible in the case of the POS. What about cases where addresses are generated publicly and no backend exists to provide an API? I'm typically thinking about the way ETH-XMR atomic swaps work. 07:09:39 I want an interactive payment protocol for Monero, and PSK makes a lot of sense for one. I would love to be able to pay with my wallet and the website communicating directly to negotiate payment. There are lots of advantages to that, and I want Monero to move in that direction. But currently there are many use cases that require a reusable unchanging address. 07:09:39 Since there's a footgun with address reuse in PSK, I think PSK makes the most sense in an interactive payment protocol, which, if properly implemented, should never expose any form of address to the user at all. Since it is compatible with Carrot, I can envision a wallet app that does both PSK and Carrot and uses PSK for payments and Carrot when the user wants a reusable address. 07:12:10 hbs: there should be no additional information through the public sharing of the psk in this case because the the interactions with the eth smart contract show up on the ethereum block explorer. the only information that is shared through knowing the psk is that someone sent to this address. but that information is implicit in the eth contract interactions 07:12:24 I remember when Bitcoin thought most payments would be interactive. There was a pay-to-IP-address feature in the original Bitcoin client. We all know how that turned out. 07:16:15 @spirobel:kernal.eu: Ok, and given the address is generated specifically for the swap the index is the first 09:13:24 We will not implement a third address format. Jamtis is overall much more versatile. It can make wallet balance recovery *almost* without scanning when using a 3rd party service and it doesn't have the disadvantages of Monero-PSK. Monero-PSK is nevertheless an interesting proposal to document. 11:26:21 lets see what happens. as this is carrot compatible, a wallet might just implement it. versatility is nice, but third party services introduce new choke points. there is a certain sense of security in instantly being able to see the wallet balance. almost via third party services doesn't provide that. 11:27:28 I don't think a 3rd party custom address format would catch on. 11:27:53 And we certainly don't want to go the Bitcoin route of having 4-5 distinct address formats. 11:38:34 tbh even in its current form the monero-PSK draft is more convincing than the jamtis draft. it states clearly what the benefits are for the users and it is not as verbose 12:42:51 We can discuss it at the next MRL meeting, but we definitely can't implement both. It should be either Jamtis or Monero-PSK. 13:23:16 yes we should put it on the agenda. but i dont see it as an either or. it will still be a while for carrot to fully land in all wallets. and this is more like a small addition to carrot. That can be experimented with and added incrementally afterwards. 13:25:29 jamtis is a bigger change that can still happen afterwards if people want the jamtis third party sync instead of instant sync. (and 464-character jamtis addresses) 13:27:01 i like some aspects of jamtis like the different merchant tiers 13:47:15 tevador: Shit I'm already exhausted just at imagining rucknium saying its time to discuss it during meeting. 15:11:21 > <@spirobel:kernal.eu> I think they would be better served if they were to sign up to xmrchat. We get more durable network effects and they get a direct relationship with their audience that youtube can't cut. Plus they can be discovered through the xmrchat creator list. Three things: 1. why is there currently no way to d [... too long, see https://mrelay.p2pool.observer/e/8eOmoIYLU1F6YVRB ] 15:11:21 I fail to see how making people sign up for a centralized donation service will make that easier. There is nothing wrong with the current way of doing it 15:12:31 If address lengths with Jamtis get too unwieldy, you could always use something analogous to Keybase for sharing static addresses 15:18:41 spirobel: "this is more like a small addition to carrot" - I disagree. It's a completely new wallet format, address format and a payment paradigm shift. Off-chain, it's completely incompatible with Carrot. 15:19:07 @jpk68:matrix.org: the problem is: these type of youtube channels that can't self host will post 10 addresses of random blipiblupi coins and it will be unlikely that they even check their wallets. for monero the case is specifically that they have to keep the wallet synced. and most likely they wont. so even if you donate [... too long, see https://mrelay.p2pool.observer/e/9pvBoIYLWkRpaVBo ] 15:19:10 and the centralization part in this case is not that bad. the donations are public in any case and the donors privacy still stays protected. 15:21:06 regarding address length: i dont think it will matter much in the future. we will find easier ways to share addresses. but it is certainly a downside of jamtis that people have mentioned. 15:26:00 tevador: for the users the experience will stay mostly the same. it will be the sharing of an address and everything else is handled transparently by the wallet. i am working on the documentation of this feature in my wallet right now. I already implemented this type of interaction in a privacy preserving way. 15:26:58 The length is the price to pay for an address that can be safely published. I still think that Jamtis is the best compromise proposal overall since we only want to introduce *one* additional address format, not two. 15:41:21 > <@spirobel:kernal.eu> the problem is: these type of youtube channels that can't self host will post 10 addresses of random blipiblupi coins and it will be unlikely that they even check their wallets. for monero the case is specifically that they have to keep the wallet synced. and most likely they wont. so even if you do [... too long, see https://mrelay.p2pool.observer/e/g9yUoYYLMmJON2ky ] 15:41:21 I can see how that might be inconvenient, but I think this is missing the forest for the trees. Does a convenience feature for Youtubers and the like justify an addition to the core protocol when, say, smart contracts don't? 15:47:38 In the case of the FSF, I have a hard time seeing them using XMRChat as well... does the site have a license for its JavaScript? Why would a longstanding and well-known organization such as themselves use a niche website that hasn't been around for very long? 15:49:41 I respect your idea, I just think its effective usefulness might be a bit dubious for a lot of people 15:49:53 @jpk68:matrix.org: sorry i dont get what your point is. maybe read the comment i was replying to. It was about what should people do that cant self host? you argument of additions to the protocol would be against jamtis, as jamtis benefit that it would serve this youtuber well with the 10 addresses that cant self host and [... too long, see https://mrelay.p2pool.observer/e/v4G0oYYLUDF5anZu ] 15:50:53 @spirobel:kernal.eu: Addresses are self-sufficient today, introducing the need to interact with an RPC endpoint opens the door to a lot of things that can go wrong, not mentioning the fact that a lot of people will not be willing to provide such a service which would require technical knowledge or will end up being offered by scammy sites for a fee. 15:51:45 @jpk68:matrix.org: nah people seem to like it: https://xcancel.com/spirobel/status/2058484807643111757#m and think its useful. there is certain sense of security that comes from being able to instantly see the wallet balance 15:52:54 maybe for some people it still seems hard to grasp because of the address sharing. but i am working on the documentation of this feature in my wallet right now. so i see the solution to this very clearly 15:53:35 My point is just that I agree with tevador that Jamtis is sufficient for this, and more complications would result in more problems than solutions 15:59:23 FWIW, if MRL decides that Bitcoin-like wallet sync should be the top priority and the drawbacks are acceptable, I could imagine Monero-PSK being implemented instead of Jamtis. 16:04:38 tevador: i think you did a great job with both proposals and I am happy either way. i just think as we scale up and get more adoption it will be hard for wallets to catch up if they have to scan all transactions, everyone is sending, all the time. 16:07:15 i implemented multithreaded, multiwallet sync in my wallet library so i know what the limitations are. I think especially with multisig there are so many new opportunties for apps. but making new wallets to participate in those needs to be cheap. 16:10:30 i really dont think there is an issue to support both jamtis and this. the purpose can be quite different: one might be used directly, the other partly automated as part of a multisig app, so the user never interacts with it directly and the exchange of the psk happens automatically. 22:53:40 Hi all. One of the things that makes monero legit is that if something goes awry, someone is going to say something. 22:53:40 It doesn't matter if monero's origins came from a scam coin if the community is legit. 22:53:40 It is time to raise the flag about skylight wallet. I pointed out how justin works for ciphertrace and I was hoping for a good explaination. Instead, i got banned for the first time from any monero group over the course of 10 years of my activity. Something strange is happening... 23:07:54 BEHOLD!!! what you are witnessing is worthy of research. A compromised character that has become an adversary. Study Justin. Learn his methods. 23:07:54 Frankly, I think ciphertrace can do better. Do theh think so little of monero devs? Silly moppets.