03:21:25 You will DO what Monero tells you to do. You will JUMP when you are told to jump. And most importantly you will DISCONNECT whoever Scientology^H^H^H^H^H I mean Mnero tells you to disconnect. Otherwise you WILL end up like lh1008 here: 03:21:26 monerologs.net/monero-community/20210114#c181614 And you will do it all for FREE. Because Monero is open souce :D Just like Linux is there to pay for $700k watches that Torvalds wears. 09:06:51 Hello all, I noticed that when trying to configure monero in one of my servers, I was getting a message about a public IP aqddress being blocked by my firewall 09:07:12 I wonder if that is something I must enable for monero mining? 09:07:26 This message came up during the syncing process 09:07:34 blockchain syncing process 09:08:29 Check your firewall documentation. Opening 18080 is a good idea if you can, but not strictly necessary. 10:11:00 Hi all! I'm trying to build a local network music discovery 'app' where musicians upload songs to a server on their local network, and then other people access that server and can listen to a radio of the songs (random order). In order to like a song and then play it back at any time you need to 'tip' the artist using monero. I took a look at https://www.getmonero.org/get-started/accepting/ 10:11:00 and https://monero-python.readthedocs.io/en/latest/transactions.html but can't quite figure out how to verify that a tip was sent to the artist's Monero wallet. 10:11:00 Is there some type of proof the tipper can provide which will demonstrate they paid some amount to the artist's address? And if so, how can I generate such a proof for any old person (i.e they don't have their own node with RPC enabled) 10:13:00 I've talked with moneromooo in #monero about some possible solutions but haven't arrived at one that would work the way I'd like. Ideally as a user sending a tip I would just scan a QR code with cake wallet (or even have it opened up via a link) choose my amount and then click send. Trying to find a way to make that experience possible 10:14:19 Depends on which wallet, IIRC this is doable on the CLI one. 10:14:57 I think most people would be using their phone so probably cake wallet, the possiblity of using the shorter encrypted payment ids https://monerodocs.org/public-address/integrated-address/ was thrown around 10:15:43 (perfect solution I think) 10:19:52 I don't think I understand how the integrated addresses work, are the public spend/view keys listed in the table at monerodocs.org the recievers or the senders? 10:21:02 ah it's the destination looking at https://www.getmonero.org/resources/developer-guides/wallet-rpc.html#make_integrated_address 10:21:03 Integrated addresses are just your (receiver's) address, with a 64 bit number appended. 10:23:23 awesome thank you, I think I have enough to give making it a go. Flow will be: users clicks 'tip' -> UI comes up and makes a request to /get-payment-address on the server -> server makes JSON rpc call to the node's make_integrated_address endpoint -> create payment QR code/link using the integrated address -> server scans for incoming txs -> invokes split_integrated_address via rpc call 10:23:23 -> uses the userid/songid which made the 8 bytes of the integrated address 10:24:01 Yes, except "server makes JSON rpc call to the node's make_integrated_address endpoint" -> the wallet's endpoint. The node does not have your address. 10:24:03 awesome thank you, I think I have enough to give making it a go. Flow will be: users clicks 'tip' -> UI comes up and makes a request to /get-payment-address on the server -> server makes JSON rpc call to the node's make_integrated_address endpoint -> create payment QR code/link using the integrated address -> server scans for incoming txs -> invokes split_integrated_address via rpc call 10:24:03 -> uses the userid/songid which made the 8 bytes of the integrated address -> records song as owned -> ui updates 10:24:43 For such low amounts, you'll probably want to check the txpool to check for txes, not wait till mined. 10:25:13 You could use tx-notify 10:25:51 (triggers a program to run on your shell when a tx is received to the wallet) 10:29:43 ah yes sorry I meant check the txpool 10:29:55 oh wow tx-notify that will be very useful 10:31:11 thank you everyone! I'll let you all know how it goes (and if I get stuck again) :) 10:32:37 Good luck :) 12:03:08 sick! good luck on it! 💯 12:22:50 Look on the bright side. At least you don't need to obsess over signs of life from FUK now. 12:29:47 It's such a coincidence that your writing this. 12:30:40 * It's such a coincidence that you're writing this. 12:30:45 https://github.com/t-900-a/gemini-jukebox-bot 12:30:56 Written two days ago 12:31:22 It's a poor mans version of what you want. 12:32:00 No user accounts, just an mp3 radio stream using mpd / icecast 12:34:50 Users can't select which music to play, and a cron pauses the music after a certain period of time. Another tx has to be sent to start it again 12:55:13 lol 12:56:43 so, I've got the portable storage serialization & deserialization working great, being now able to essentially do any req & response to the p2p network (handshake working well, able to get the whole local_peerlist_new, etc) 12:57:37 but I couldn't find in the source code anything for command 1005 (network_state) and 1004 (stat_info) - is that because Monero indeed doesn't implement it, or, am I missing something? 12:58:31 (perhaps `docs/LEVIN_PROTOCOL.md` is an antique doc from pre-monero times?) 12:58:37 When SpotXMR? 13:00:11 read the code and ignore that doc 13:02:46 wfaressuissia[m]: yep, just double checking if I'm not missing anything (new to the codebase) 13:13:51 It's current. Those are in src/*/*defs.h 13:14:10 Oh, they are debug calls, might have been removed actually... 13:14:19 They were defined out for ages anyway. 13:27:19 coooll, thx for confirming! 👍️ 13:31:38 They were removed last year, I just checked. 13:58:00 aren't integrated addresses on the way out? 14:00:36 Unclear. 14:01:44 Would be nice to (1) kick them out and (2) add an always on fixed size per output encrypted field. Could be used for that and other things. 14:09:13 Starting from 6th May, I'd like to try to abstract the wallet2 class a bit, using an interface. Does anybody have something against it? vtnerd ? 14:10:31 * moneromooo encourages smaller diffs if possible and waits to see where this goes 14:11:06 Of course. 14:30:52 its already abstracted once 14:31:00 in wallet/api 14:47:26

What were you looking to abstract? 15:51:40 vtnerd, What is the reason why wallet2 class inherits no interface? Is there a relationship between wallet2 and api/wallet? 15:52:19 virgildante[m], I'd like wallet2 to inherit from something, so that the clients don't have to include wallet2.h directly. 16:01:48 wallet2 doesnt need to inherit from something for other code to use its contents 16:01:51 as we discusssed 16:02:14 its functions have been factored out while largely keeping existing interfaces 16:02:25 those factorizations can simply be PR'd to monero 16:03:07 inheriting wallet2 from something would be fine iff what it inherits from is an object so designed as to be truly more general 16:03:16 but what is wallet2 a specific case of? 16:04:17 it wouldnt help much at the moment to go in that direction immediately IMO since no one has need of a more general case - what they need are the contents 16:04:50 nor would it help to chuck another interface on top of wallet2 as vtnerd noted 16:05:57 From the design point of view, at the first iteration it would be enough if wallet2 just inherited from an interface which contained all of the wallet2's methods. It doesn't mean that that iwallet2 would be the generic case. This means that iwallet2 could in future inherit from a truly general wallet interface, as you design it. 16:06:02 mymonero-core-cpp shows, as we discussed, those factorizations.. so that work is already done and needs to be PR'd to monero 16:06:30 that doesnt sound useful mj 16:07:07 wallet2 already has an interface. it actually has two now 16:07:18 its header's entire point is to be an interface 16:07:29 and all instantiators of it consume that interface 16:07:53 Depends on the point of view. Generally no user should have to include the header, where there are any private members. wallet2 is not an interface. It's an implementation already. 16:08:18 And this is especially true for a large class like this. 16:09:34 sigh 16:09:51 endogenic: no you don't get it, we need to change it for the sake of changing it ;D 16:09:52 sounds like youre not asking for anyone's differing opinion 16:09:57 lol :)) 16:10:24 i have been promised funding to do this work 16:10:35 $120k 16:10:41 That attitude is the reason why it takes bloody 50 minutes to compile the project (and not only this one) 16:11:03 but we'd need someone who has enough experience with growing and maintaining codebases and building objects 16:11:20 no mj 16:11:25 it's not the cause 16:12:32 it is exactly the cause. Here's the proof 16:12:33 http://enjo.hopto.org/pub/monero/data/e45619e61/e45619e61-cba-result.txt 16:12:44 search for" 16:12:45 wallet2.h 16:14:00 endogenic> sounds like youre not asking for anyone's differing opinion <-- the only differing opinion I could extract from this is "DONT DO IT" 16:15:40 correct 16:15:43 dont do what you suggested 16:15:49 But OK. As you can see from the above report, there are many other files like this, which make the project compile for so long because of the same attitude, so I'm fine avoiding it, until somebody asks me to do it or I run out of ideas. 16:16:13 if i'm not mistaken mj-xmr_, you used my name and referenced my talk in 2019 in order to raise money for this task 16:16:26 meanwhile you told me you never looked at the work i did on it 16:16:33 you never saw mymonero-core-cpp 16:16:37 that effort isnt just my own 16:16:51 it include's ndorf and even some of vtnerd's work 16:16:54 For this task alone I arranged about 4 XMR. I'm fine to redistribute it. Gee. It's yours. 16:16:59 there's a reason we didnt just make a iwallet 16:17:19 well if you insist it would be the second donation i've ever received 16:18:09 Honestly with such raising prices in USD terms, I will defo ask the team to redistribute a big chunk of that funding. 16:18:26 but you should keep the money and review existing work and try to absorb the wisdom behind it as you have skill in c++ and can benefit monero 16:22:09 meanwhile you told me you never looked at the work i did on it <-- and this is kind of crappy public shaming. Not a gentlemen's way of dealing with differences in opinions. 16:22:19 fwiw I agree, there's still far too much actual implementations in header files 16:22:35 which is definitely a burden on compile times 16:22:49 you're projecting, mj-xmr_ 16:23:51 and you're upset that i didnt let you walk all over me 16:23:58 Not at all :) 16:24:04 I'm a lone wolf. 16:24:06 oh yeah you actually like that then 16:24:11 mudslinging 16:24:58 I'll just leave it there. 16:25:07 And do some real work. 16:25:13 So wallet2.h would inherit from the new interface? 16:25:32 yes dont waste your time 16:28:12 virgildante[m], yes. 16:29:07 wallet2 already has an interface that changes on a regular basis 16:40:48 Triptych prioritization meeting in ~20 minutes 17:00:23 Hello 17:00:43 Hi 17:00:46 cc rehrar, binaryFate 17:00:47 Hi there 17:00:48 Hu 17:00:51 hi 17:01:05 hi 17:02:15 Who wishes to lead this meeting? 17:02:23 hello 17:02:31 binaryFate: Would you mind leading? 17:03:24 Unfortunately I cannot. Sorry. 17:03:32 So we leave it to somebody. 17:04:06 I'll probably have to leave early. Sarang do you want to have a go? 17:04:10 OK 17:04:45 I am interested to know what Triptych research priorities should be, to determine if I should work on it as part of a CCS submitted by rehrar 17:05:01 Note that I would be working as a researcher employed by rehrar's company 17:05:26 I had previously understood that multisig was not considered a very high priority, but now it sounds like it should be, for example 17:05:37 I vote (1) correctness, (2) security, (3) multisig, (4) speedups. 17:05:40 So it seems best to identify priorities more directly; hence this meeting 17:05:43 Hi 17:05:45 proposal: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/222 17:05:46 For people reading, sarang submitted a CCS proposal -> https://www.reddit.com/r/Monero/comments/mn3irk/triptych_research_and_optimizations_a_new_ccs/ 17:05:56 No, rehrar did 17:06:03 Just to be very clear 17:06:36 To be even more clear, Cypher Stack did. 17:06:51 There was much discussion about the nature of that arrangement, but I'd specifically like to determine the priorities to know if I am the best person to do that work 17:06:54 But I, the individual, submitted it in behalf of the company because companies don't have typing hands. 17:07:24 mj-xmr_ : if the goal is compile-time reduction, then no doubt much could be moved using the pimpl method 17:07:38 would it be appropriate to add ring selection to mooo's list? AIUI increasing the rind # would require a new selection algo 17:07:40 but I'm not sure why at a glance an vtable interface is needed 17:07:57 Here are some things that I had considered useful research? 17:08:02 s/?/: 17:08:12 - Output selection and binning algorithms 17:08:21 - Batching optimizations 17:08:28 - Verifier optimizations relating to scalar computations 17:08:39 - Updates to security model 17:09:29 As far as multisig goes, I had initial work on this but it's more complex than the current multisig solutions and would require much more coding using something like OpenSSL for RSA groups 17:09:41 Hey. I'm one of the xmr.to team. Multisig is definitely be an important enabler for at least one of our upcoming projects. And quite a major bummer if we lost it :-). So I would like to add my vote for multisig. 17:10:03 I do _not_ know how much complexity this would add to things like mobile wallets or hardware wallets 17:10:28 To be absolutely clear, this requires curve arithmetic that is not 25519-based 17:11:05 and is multi-round 17:11:08 I'd say it's an acceptable drawback if you have to use monero-wallet-cli to use multisig. 17:11:13 I will add a vote for multisig support with the recent announcement and impetus behind Haveno. That's a high priority for me, personally, now. 17:12:04 I am not very familiar with OpenSSL or its alternatives when it comes to functionality required for this RSA group support, so the implementation side is something I'm much less confident in 17:12:06 sounds fine if it's only in wallet-cli for now. someone else can adapt it for mobile wallets at a future time 17:12:08 I'm thinkinf of people with large amounts of monero and mandated DD. Those would have to use multisig, most likely. Kind of a must have for those. 17:12:16 I am more confident in the underlying construction and algorithms 17:12:19 sarang: appart from significant additional coding, would the security model be fundamentally different for multisig than for singlesig? 17:12:32 I can help with openssl if needed. I'm not familiar with it, but I can become :) 17:12:50 A vague hope, but would it help anything if only 2/3 was supported? Because that's basically where almost all the shows take place. 17:13:04 binaryFate: the existing security model holds, since it doesn't care how you compute keys or linking tags as long as they're correct 17:13:06 I see backwards compatibility with existing multisig as a requirement 17:13:16 ArticMine: key image format changes 17:13:22 why would only wallet-cli have access to the implementation? 17:14:06 for us "backwards compatibility with existing multisig as a requirement" would be a nice to have, but not a have to have 17:14:07 Assumes facts not in evidence. AFAIK the issue is processing power (for hw wallets) and more code to use the wallet2 impl. 17:14:12 or was that just 'it might be too much to add to a hwdevice scheme for now' 17:14:12 I'll throw my support for openssl rsa groups too, man 17:14:27 ty 17:15:26 I've worked pretty extensively with OpenSSL, am available to help on that front 17:15:32 So what happen to existing multisig outputs? there needs to be a pathway 17:15:34 endogenic: hardware wallets would need to be able to do arbitrary RSA group computations, and I don't know enough about their capabilities 17:15:39 yeah 17:16:16 Old outputs would continue to use the old key image format, and need to be "transitioned" to new outputs... this would likely just be a height cutoff 17:16:20 Are there any HW wallets that support *current* multisig? Don't think so. 17:16:28 This means a partitioning of the output set, which has important implications 17:16:31 They should be able to be spent normally. When spent, they'll generate triptych outputs. Whether those are multisig or not is unknown to the sender. The recipient can then send them normally. 17:16:39 However, I do not know of a way to avoid such a partitioning 17:17:26 this doesn't sound any different from transition to ringct, or transition to BP 17:17:44 As for optimizations, there's a neat optimization that was used in Beam and Firo's implementation of Lelantus (disclaimer: I do research on Lelantus as part of my role at Cypher Stack) 17:17:51 Similar to the ringct change, BP did not need such a change. 17:17:55 Correct 17:18:01 ^ moneromooo correct, not hyc 17:18:45 The transition like the ringCT model should not be an issue as far as I can see 17:18:57 reference to Lelantus doesn't give warm fuzzies, given Firo's recent problems 17:19:12 It means an initially limited anonymity set, which will cause initial chain reaction deanonymization 17:19:27 hyc: Triptych and Lelantus share the same "proving system ancestor" 17:19:31 as does Arcturus 17:20:24 and this optimization applies to part of the protocol that happens to be common among them 17:20:44 I have yet to determine the precise timing differences 17:21:36 sarang: To be clear, in that case multisig should be able to 'hold' funds past the fork date right? 17:21:50 A output conversion subsequently takes place when the 'old' outputs are consumed in a transaction 17:21:53 That generates new Triptych outputs 17:22:32 Output conversion means that a transaction can include either _only_ pre-Triptych anonymity set elements or _only_ post-Triptych anonymity set elements 17:22:48 and the linking tag pool used for checking double-spends is specific to that cutoff 17:23:20 The output format itself isn't actually changed, but that's not really important here 17:23:52 Doesn't sound like a reason to fully kill multisig to me 17:24:09 More like "issues" 17:24:16 IMO if there is a known Triptych optimization it is worth exploring, even if the exact speedups are not known yet 17:24:20 Or "things to consider" 17:24:39 agreed 17:24:47 Yeah, there's a separate optimization that affects proof format (using `n`-ary Gray codes) 17:25:12 The other optimization is not consensus, but it could be important for setting network parameters for the proofs 17:25:12 we want to consider and explore all known optimizations before deploying triptych 17:25:16 to avoid multiple forks 17:26:20 yeah that makes sense 17:27:15 Anyway, it does sound like multisig _at fork time_ should be considered a blocker now? 17:27:21 sarang: Is this conversion only needed for multisig, or for all outputs? 17:27:29 All outputs 17:27:34 Very similar to the RingCT transition 17:27:41 I don't see the issue then, at least for that aspect 17:27:43 Multisig outputs look identical (by design) 17:28:00 Well, the conversion is important because it _will_ initially lead to chain reaction analysis 17:28:07 The issue is lots of new code using RSA groups has to be done. 17:28:10 This should dissipate quickly 17:28:12 moneromooo: yes 17:28:47 sounds like a flag day. tell everyone to churn after the hardfork. 17:29:27 sarang: What time frame would you estimate to get multisig properly working? 17:29:35 Any rough estimate possible already about how many person month we talk here? 17:29:55 For the implementation 17:30:37 That's the thing... I don't have a solid understanding of what full multisig implementation will take, since it's multi-round and uses a lot of new group arithmetic that we currently don't use anywhere 17:30:53 I can maybe add some wallet code to prefer spending pre-triptych outs. This means that there'll be fewer trpitych txes right after the fork, allowing for more new triptych outs to be created before the first ones get spent. 17:30:55 We also have to support old non-ringct -> triptych transactions no? 17:31:13 No, IIRC those go pre-rct -> rct. 17:31:41 This would make a chain pre-CT -> CT -> Triptych easy to detect, FWIW 17:31:46 ah, so someone with pre-rct would have to do: pre-rct -> rct -> triptych? 17:31:54 Similar to how 'unmixable' outputs are first transformed non-ringCT outputs I guess 17:31:58 Of course, spend patterns for CT -> Triptych may be easy to detect as well based on known distributions 17:32:18 They don't have to. The outputs are created in the type that matches consensus rules. They're always all spendable. 17:32:20 Anyway, I think a lot of this transition needs careful consideration since it's a big change 17:32:46 Yes I agree 17:32:48 The work I did previously was on the proving system and a _bit_ of the multisig stuff 17:33:02 But there's a lot to consider about the migration, and any side cases that might arise 17:33:13 But still enough for moneromooo to implement a POC, right? 17:33:14 as well as the practical implementation of multisig due to its RSA group requirements and round structure 17:33:36 rbrunner: my initial multisig work is almost certainly not enough for a proof of concept yet 17:33:44 But I can write it up in much more detail 17:33:48 No, I meant Triptych in general 17:33:53 The initial stuff was just to determine if such a thing was possible 17:34:04 Oh, I have working Triptych prover and verifier code already, with limited batch support 17:34:17 That was done earlier to get timing data 17:34:19 Well, the patch to add triptych to monero is done. 17:34:28 Yes, that's what I meant :) 17:34:30 I did that a couple months ago. 17:34:46 Big caveat that while the preprint has undergone review for publication, the code has undergone no such formal review 17:35:00 And, as always, the quality of peer review can vary greatly compared to a paid review 17:35:07 ^ for the preprint, I mean 17:36:37 I know people are excited for the big ring sizes, but this shouldn't be rushed in any way. I would be shocked if we wanted to get this in before year's end. 17:36:47 sarang, you mentioned " - Updates to security model" as possible themes. What's that, in general? 17:36:58 We can release with BP+ in the meantime. 17:37:15 Big caveat that while the preprint has undergone review for publication, the code has undergone no such formal review <= We would have to get multiple audits for Triptych anyway 17:37:27 rbrunner: the current security model focuses primarily on the proving system itself as a zkp system 17:37:46 rehrar: I'd still be in favor to postpone BP+ until Triptych is ready, even if that means we have to postpone it to, say, early 2022 17:37:54 But less so on the resulting transaction model that you get by using our commitment-offset-based approach to amount balancing 17:38:14 FWIW the CLSAG security model is similar, as was MLSAG 17:38:29 Arcturus is a little different since it handles balance inside the zkp, whereas Triptych (and its predecessors) do not 17:38:47 would triptych multisig require specific paper peer review? 17:39:57 It would be nice if it did 17:40:14 Working up a separate security model for that would be a _lot_ more work (think about the previous multisig preprint!) 17:40:36 The most one could hope for without that would be a thorough description and proof of concept, but this is a very different review process 17:41:03 Also, multisig security models were really suraeNoether's expertise 17:42:49 The idea behind multisig is that to compute the linking tag between players requires a type of known MPC 17:43:06 and then this is worked into the rest of the proof construction, which is much more straightforward 17:43:20 The RSA group stuff only comes into play for this linking tag MPC 17:43:41 and there only because you need to jointly compute an inversion of the output secret key 17:44:01 (multiplied by a fixed curve group element, that is) 17:44:28 Hello everyone! Sorry I am late to the party... Is there a live transcript/log somewhere so that I can see was has been said till now? 17:44:41 arnuschky: I'll send the logs in PM 17:44:49 https://monerologs.net/monero-dev/20210421 17:45:33 awesome, thanks 17:46:10 And solutions like allowing a mix of transaction formats for the foreseeable future fully out of question? 17:46:30 No. 17:46:30 How do you mean? 17:47:05 We freely allow people to produce the current tx format even after hardfork. People sneak in their multisig transactions that way. 17:47:11 That would imply multisig holders performing current transactions, whereas the rest of the network performs Triptych transactions 17:47:40 Not necessarily. I mean crazy things would be possible, like random decision what to produce for *every* tx :) 17:47:47 Consensus rules cannot distinguished between outputs that were spent from a multisig wallet from outputs that were not. 17:47:49 sarang: Given the potential volume of the multisig work, would it be prudent to start with that aspect of Triptych? 17:48:04 dEBRUYNE: certainly could do this 17:48:10 if there is general agreement that lack of multisig is not acceptable, doesn't that define an apparently large enough (listening to sarang) research direction already? 17:48:22 binaryFate: Right 17:48:32 moneromooo: I meant in case of a fork without multisig support for Triptych 17:48:34 If multisig is a blocker for deployment, that could be the initial scope; if it turns out not to work in practice for whatever reason, that minimizes any wasted effort 17:48:42 Then multisig holders can only transact in the old format basically 17:48:59 just curious: does arcturus lend itself to a better / easier multisig? or is it the same? 17:49:15 To be clear about any kind of mixing of transactions... outputs need to be separated by what transaction type can consume them 17:49:24 If we fork without MS, and if Alice has a MS wallet, and Bob sends Alice an output after the fork, then Alice cannot spend. That is bad. 17:49:32 Arcturus multisig requires this as well, as would Omniring, RingCT 3.0 17:50:35 You could not prevent that sending, right, because multisig is not visible in the address 17:50:54 So how would a transition from Triptych to Arcturus look like for example? 17:51:15 ArticMine: output pool stays the same 17:51:19 yeah it sounds like multisig is the primary at this point 17:51:25 Proof format changes 17:51:39 No transition needed for outputs between Triptych and Arcturus 17:53:24 In that case, should the initial scope of work be multisig only? 17:53:38 Yes 17:53:55 Maybe, given how far along the "other" stuff is already ... 17:53:57 If we cannot deploy without multisig, it is basically imperative to find out as soon as possible whether proper multisig can be implemented / achieved 17:53:57 Output binning/selection is important as well, but seems less important based on this discussion 17:54:46 binning sounds like a matter of refinement, MS sounds like a harder works/won't work 17:54:47 I mean we don't even have any graceful way out of multisig on the table if we really should drop support, right? 17:55:00 hyc: binning would likely need to be consensus to avoid miner shenanigans 17:55:00 If multisig is in such high demand, but seems conceptually not really an issue but much more a coding problem - would it be sensible to turn this into a separate CCS and fund that alongside the more theoretical Triptych work? 17:55:07 I agree with dEBRUYNE. Nice to see all the support for multisig and haveno :) 17:55:08 Other than "People, please empty all those multisig wallets" 17:56:09 true arnuschky . sarang, at this point, is multisig more a theoretical problem or an implementation problem? 17:56:51 or is it in that wonderful gray area ..... 17:57:21 Mostly implementation, but I think the transition should be reviewed in more specificity to ensure that existing multisig wallets are not affected 17:57:33 Loss of funds seems like the obvious blocker 17:57:48 We'll all agree on that 17:57:49 As would having to move to a separate multisig arrangement? 17:58:09 i.e. if multisig players need to collaborate to migrate to a new address 17:58:22 well, theoretically, they can migrate whenever 17:58:28 I suppose that is not necessarily a blocker as long as there is no time limit on it 17:58:29 I think migration is fine as long as it's not time-constrained 17:58:29 Certainly unfortunate 17:58:40 Bit inconvenient, but still 17:58:47 ie if I want to recover my wallet two years from now, it should still be possible 17:58:52 Should it be considered a blocker if multisig players need to change addresses? 17:58:57 2/3 looses sense, opens blackmail possibilities that were not there otherwise 17:58:58 rather than resulting in loss of funds due to a missed window 17:59:00 Or just a super duper annoyance 17:59:18 Same answer I'd say 17:59:21 Just inconvenient 17:59:24 for us that would be acceptable 17:59:39 sarang: would be defintely be problematic. I'm not sure of how that would effect active trades on Haveno. 17:59:40 sarang: I think it should be fine as long as a proper migration guide is provided 17:59:43 Better than no multisig in any case :) 17:59:45 That lays out all necessary steps 17:59:46 Anyway, this is good to know. So the general consensus seems to be that limited scope initially to multisig is the best use of effort? 18:00:00 I'd say so 18:00:08 inconvenience can always be softed by good software support / processes 18:00:11 but if the price to pay for multisig support, i guess could be workable :) 18:00:37 I'd be hesitant to expand scope if one outcome could be "sorry, multisig doesn't work, so it's all canceled!" 18:00:45 yeah 18:00:52 "limited scope initially to multisig is the best use of effort" +1 18:01:00 So what say we leave the existing proposal as is, and just not merge. It'll just chill in Ideas. Make a new proposal for multisig work with the scope and price. Get discussion on that. Merge that one first once approved. 18:01:14 Why not close it? 18:01:16 Then the Triptych optimizations can be merged after multisig is sorted out. 18:01:30 Any further work would need a more defined scope than existed in that CCS 18:01:43 Why not change the existing one? 18:01:52 Up to rehrar I suppose 18:01:59 dEBRUYNE: all of the comments will be for the old version, wouldn't be obvious 18:02:56 We are not short in possible proposals, aren't we. Cleaner certainly to make a new one, IMHO 18:02:57 and there's a lot of comments. I think it's important for the transparency. A new lurker will see all of the comments and think they are in support of the multisig stuff. Which those people may very well be in support. But I think it's best to be clear? 18:03:01 I guess, but most of the discussion relates to the way sarang is contracted 18:03:09 Not to the specifics of the proposal itself 18:03:34 I will do what the community thinks is the best course of action for the proposal itself. 18:03:54 I'd change the scope, cite this meeting as source 18:04:01 And then simply merge it 18:04:03 Also think no reason to open a new proposal. 18:04:19 Would be a bit of shame to lose another week here just for redundant administrative purposes 18:04:31 One issue is that I don't have a good sense of the time commitment required for this 18:04:41 Multisig, that is 18:04:44 As noted earlier 18:04:49 sarang: I'd just work out the current hours and see how far you get? 18:05:28 Sounds reasonable. 18:05:55 We could hold another meeting afterwards I suppose 18:05:58 Not much choice, given all the unknowns and uncertainties 18:06:01 I agree. And since the time is on the smallish side (one month's worth of work hours) then we can reassess at the end of that. We're underestimating rather than over, so no risk to the community on unused funds. 18:06:08 +1 I'm quite comfortable with letting Sarang work on it and revisiting status and progress once we know more. 18:06:21 agreed 18:06:29 Yeah I want to avoid the case where it takes much less time than expected, and funds were raised in excess 18:06:53 Buy a lambo then :) 18:07:06 oof 18:07:07 Depending on the status of multisig, I presume those hours can simply be used to work on other aspects 18:07:10 If it takes less time, and multi-sig is found to be likely to have solutions with Triptych, I would also be quite comfortable with sarang spending excess time on any of the other proposed tasks :P 18:07:21 I'm sure core would be fine with any excess funds (if it were to ever happen) to be rolled into any next research project we do. 18:07:32 The worst-case scenario would be discovering that it won't work early on 18:07:39 making the other work moot 18:07:41 sarang: I think the community is perfectly fine with letting you churn away on Triptych 18:07:57 The worst-case scenario would be discovering that it won't work early on <= Which is basically why multisig has to be prioritized 18:08:08 dEBRUYNE: well, what he's saying is it seems multisig is a showstopper. So if we realize it's not workable, then Triptych is a no-go altogether. 18:08:09 Sorry, was afk for a bit, just reading this: "Should it be considered a blocker if multisig players need to change addresses?" 18:08:15 Meaning excess hours can't be poured into Triptych. 18:08:36 I think it would be a massive problem, because you can't stop people from sending to the old address, where the outputs would apparently be burnt ? 18:09:13 In what kind of scenario does a multisig wallet receive a lot of transactions though? 18:09:23 Without flagging the output type, yes 18:09:29 Hot wallets (from services) are typically not multisig as far as I know 18:09:40 Again, need to carefully consider the transition and existing addresses 18:09:52