10:33:42 Will you HODL Monero or dump it for Tari when it comes out? 16:58:35 sarang: Would it be worthwhile to have a specific meeting about -> 'there are considerations for important topics like multisignature support and output migration that warrant much more thorough discussion before a deployment ought to be considered.' 17:44:02 For sure, but as I've said a few times before, I don't know what computational requirements, if any, we should be targeting for multisig support 17:44:34 If we need/expect computationally-limited hardware wallets to be able to do this, that's a strong limitation 17:44:52 but I can't answer whether or not this is needed 17:45:03 do hardware wallets like trezor and ledger generally support multisig even for bitcoin? 17:45:15 Multisig a hw wallet cannot do is better than multisig noone can do. 17:45:26 I guess if they work with electrum? 17:45:47 We would need more general RSA group support, but a general library like OpenSSL would be able to handle it with some work 17:45:58 (the limitation is general RSA groups) 17:47:15 * moneromooo a bit puzzled about RSA appearing here 17:47:56 Meaning prime-product groups 17:48:07 It's not the RSA algorithms per se 17:48:56 for Paillier encryption/decryption needed for multisig 17:49:58 ty 17:50:24 Downside is that the primes are selected by the users; they aren't fixed globally 21:17:53 I'd rather kill multisig for Ledger/Trezor than not have Triptych or Arcturus 21:34:48 Ditto. Also... *how much* more computational requirement are we talking? If HW wallets will handle that in ~5 years' time, it's a limited problem 21:38:39 sgp_: +1 21:38:56 I think as long as we have 'standard' multisig support plus standard hardware wallet support, there will be little complaints 21:39:19 right, people can still use non-multisig on those devices 21:42:05 Cool 21:42:32 sarang: what would it take for us to feel more comfortable in the atypical assumption in Arctutus? An audit? 21:43:38 Why not play it safe and simply select Triptych? I think the advantages of Arcturus were not that substantial (I may be off here, sarang can clarify probably) 21:44:01 Space benefits; verification time is comparable 21:44:40 https://usercontent.irccloud-cdn.com/file/P5l04TUL/paper%20page%2013 21:44:49 space benefits >10% 21:45:42 Would a Triptych -> Arcturus migration be possible at some point? 21:47:11 for the record, I still support Triptych, but it would be interesting to see what extra effort Arcturus would take since the benefits are not something to dismiss entirely imo 21:47:16 Not sure 10% is worth the risk of having atypical assumptions 21:47:24 Space is arguably fairly cheap, especially in comparison to verification time 21:47:37 I agree verification time is more important 21:48:45 hard to tell exactly from the chart, but looks like ~20-25% smaller? 21:48:58 Isn’t this batching related? 21:49:21 verification is effectively the same for both 21:49:25 batched and unbatched 21:49:46 Right, I meant the space benefits only come with batching compared to Triptych IIRC 21:50:47 maybe I'm missing something, but why is batching relevant for tx size? 21:52:25 I meant multiple inputs, batching was the wrong word 21:54:38 here are the charts sarang posted a while ago 21:54:47 1 input: https://usercontent.irccloud-cdn.com/file/DYMoX7jy/size-1.png 21:55:22 2 inputs: https://usercontent.irccloud-cdn.com/file/7Hw5Wnsv/size-2.png 21:55:29 16 inputs: https://usercontent.irccloud-cdn.com/file/QzJ03VBI/size-16.png 21:56:10 sarang would know for sure but that's how I would interpret those three charts 21:56:31 the arcturus paper showed the verification times for Monero txs from 18 October 2018 to 14 February 2020 21:57:41 if we switched to Arcturus, we'd probably have to change the txs fees to incentivize large-input-# transactions somehow 21:58:41 obviously not too much incentive, but to enough to fairly encourage one tx with many inputs over several with fewer inputs 21:59:22 that sounds ike something of only temporary value. for people with lots of dust in their wallets 21:59:51 makes batched payments cheaper too 22:00:07 batching is for multiple outputs, no? 22:00:17 why this focus on number of inputs? 22:00:44 just because the cost of the verification is lower per input as the # of inputs increase 22:00:46 Many-input-# transactions are less private, see EAE attack 22:01:07 sech1: well, "it depends" :) 22:06:09 back to arcturus vs triptych, it's unclear to me what if anything we can do to feel comfortable with arcturus 22:06:19 I clearly don't have the skills to assess that 22:11:43 I have the same question as selsta about feasibility of Triptych -> Arcturus migration at some point 22:19:29 there are charts similar to above for verification time that I can't find at the moment dependent on the ringsize 22:19:38 I remember Arcturus have a verification time advantage but 22:21:51 *****there are charts similar to above for verification time that I can't find at the moment 22:21:56 I remember Arcturus have a verification time advantage but dependent on the ringsize 22:27:18 Arcturus and Triptych share the same key image format, so switching the required proof from one to the other in consensus is possible without an output set migration 22:28:23 Input count is indeed where you see Arcturus shine, since it requires only one proof per transaction... Triptych (like CLSAG and MLSAG) requires a proof per input 22:31:57 Most transactions either have 1 or 2 inputs though, so for those Arcturus wouldn't have a significant impact, correct? 22:37:59 dEBRUYNE: the chart at the bottom of the Arcturus paper showed the numbers for real Monero transactions over that 1.5 yr window 22:38:25 average # of inputs is >2 iirc, but someone did the numbers on this at some point 22:40:18 https://github.com/noncesense-research-lab/tx_in_out_distribution 22:41:30 Thanks 22:43:53 2.7 average RCT only 22:44:51 90% 1 or 2 in