03:46:09 <bridgerton[m]> <joshhavepigdog> Question: Would you guys (devs and maintainers) be open to adding a block size limit (like Bitcoin currently) to Monero at some time in the future IF adoption (daily tx’s) rapidly outpaces HDD and SSD storage solutions/options available at that future time? 
03:46:09 <bridgerton[m]> My understanding is that most of you (the team) think this rapid mass adoption is unlikely in the short term (I agree with you), however under the unexpected circumstances where we observe the chain expanding rapidly relative to storage solutions (we are feeling squeezed), would you all be open to adding a block size limit? I’m referring to a worst case outcome here in which the Blockchain is more than 2 Terabytes (for
03:46:09 <bridgerton[m]> example).
03:46:34 <bridgerton[m]> <joshhavepigdog> Question: Would you guys (developers, researchers and maintainers) be open to adding a block size limit (like Bitcoin currently) to Monero at some time in the future IF adoption (daily tx’s) rapidly outpaces HDD and SSD storage solutions/options available at that future time? 
03:46:34 <bridgerton[m]> My understanding is that most of you (the team) think this rapid mass adoption is unlikely in the short term (I agree with you), however under the unexpected circumstances where we observe the chain expanding rapidly relative to storage solutions (we are feeling squeezed), would you all be open to adding a block size limit? I’m referring to a worst case outcome here in which the Blockchain is more than 2 Terabytes (for
03:46:34 <bridgerton[m]> example).
03:47:19 <bridgerton[m]> <joshhavepigdog> ^^^ This is a good ArcticMine question, but I doubt he will see this message 😦
03:48:32 <CidadoisAncap[m]> Bitcoin 1mb blocksize is so pathetic
03:49:13 <CidadoisAncap[m]> I went all in monero for its l1 scalability rather than default privacy
03:49:34 <CidadoisAncap[m]> Even tho both features contributed for such decision
03:54:07 <bridgerton[m]> <joshhavepigdog> I understand your reasoning completely. My point in asking is that if the Monero blockchain  is greater than 2 terabytes prior to 2030 and storage solutions haven’t improved, would the Monero team be open to implementing a block size limit *only as an emergency measure*
03:55:20 <bridgerton[m]> <joshhavepigdog> I think adding one in now is unnecessary. I can only see it making sense if there is rapid mass adoption and we are getting squeezed in storage space.
04:00:05 <CidadoisAncap[m]> I get it, i'm just trash talking bitcoin
04:02:10 <bridgerton[m]> <joshhavepigdog> Gotcha. I hope one of the developers or researchers sees my message tomorrow. I’m curious to hear if they would be open to a block size limit *only as an emergency measure*
04:09:27 <CidadoisAncap[m]> There are monero core devs in this room?😳😳😳
04:10:04 <CidadoisAncap[m]> Can you guys say hi to nakamoto for me?🤙🤙🤙
07:07:19 <merope> We already have a blocksize limit. The difference is that it's not a fixed, hardcoded value, but it's dynamic
07:07:33 <merope> But there are limits to how much and how fast blocks can grow
07:09:41 <r4v3r23[m]> merope: when was dynamic blocksize added?
07:09:51 <r4v3r23[m]> and what was the limit before?
07:10:51 <merope> Don't know, but it has been here a long time
07:17:21 <sech1> In March 2015
07:17:44 <sech1> no, wait. Tail emission was added in march 2015, not sure about dynamic blocksize
07:18:39 <sech1> I think it was from the beginning
07:21:41 <sech1> yes: https://bytecoin.org/old/whitepaper.pdf 6.2.2 Size limits
07:53:35 <r4v3r23[m]> <sech1> "I think it was from the beginnin..." <- excellent, thx
10:59:26 <plowsof> if storage solutions don't improve by 2030? :( 
11:01:28 <plowsof> we'll have flying cars (helicopters) in 2030 and call of duty version 100 will be 10 petabytes (im sure storage solutions will improve(?))
11:10:28 <bridgerton[m]> <plazma> we need transmissions of monero blocks in all forms of communication like onion network garlic network radio network satellite network mesh network and more
11:10:56 <bridgerton[m]> <plazma> to be truly decentralized
11:11:46 <bridgerton[m]> <plazma> onion share and cwtch software application should have native monero support
11:14:06 <bridgerton[m]> <plazma> Briar also should have native monero support
12:14:44 <merope> Spamming this in multiple channels will not help get it done, plazma
12:15:41 <merope> If you want Briar to add native Monero support, your best course of action is to start working on the implementation and open a PR in their repository
12:15:59 <merope> Same for onion share and cwtch
12:33:31 <plowsof> marketing campaign also ' the Briar switch project ' ! i dont know what brair is but they should switch to using monero 
12:34:54 <plowsof> also fix 'reference implementation' first, moneros anon p2p traffic needs work? bitcoin is leading in that aspect? not sure on the specifics 
13:06:05 <r4v3r23[m]> what would the technical term for a crypto wallet be?
13:06:08 <r4v3r23[m]> keyring?
14:32:58 <cryptogrampy[m]> database editor
14:50:55 <r4v3r23[m]> a wallet holds funds
14:51:03 <r4v3r23[m]> our "programs" hold keys
14:51:24 <cryptogrampy[m]> a wallet does not hold funds, it's just a portal to a database
14:51:51 <cryptogrampy[m]> er
14:51:52 <cryptogrampy[m]> yeah
14:51:54 <r4v3r23[m]> a wallet holds funds
14:51:55 <cryptogrampy[m]> what you said
14:51:55 <plowsof> like how a credit card doesnt hold any money (same concept) 
14:51:56 <cryptogrampy[m]> :)
14:52:01 <r4v3r23[m]> right
14:52:05 <r4v3r23[m]> but your wallet has bills
14:52:12 <plowsof> oh physical wallet
14:52:21 <cryptogrampy[m]> plowsof: wow big brain discussions today
14:53:11 <cryptogrampy[m]> a wallet has bills, my safe has gold and wownerochans
14:53:16 <r4v3r23[m]> i dont think "wallet" accurately describes the software we use to ineract with monero
14:54:04 <cryptogrampy[m]> monero.... account
14:54:20 <r4v3r23[m]> btw cryptogrampyis there a mobile wallet that is rpc based instead of traditional scanning
14:54:34 <cryptogrampy[m]> yes there are a few
14:54:56 <cryptogrampy[m]> tevador: did a prototype wallet that was server side/bundled with wallet-rpc
14:55:08 <cryptogrampy[m]> woodser built a very simple one with monero-javascript library
14:55:18 <r4v3r23[m]> what would be the adcantages
14:55:30 <cryptogrampy[m]> and reeemuru built a browser extension wallet
14:55:39 <r4v3r23[m]> from what i see current wallets are just GUI wrappers for the cli wallet on android
14:55:39 <cryptogrampy[m]> also prototype
14:56:11 <cryptogrampy[m]> the advantages of a wallet that connects to wallet-rpc are that it's instant sync to the person using the wallet
14:56:32 <cryptogrampy[m]> the syncing happens server side
14:56:32 <r4v3r23[m]> so the wallet functions are on the node itself
14:57:01 <cryptogrampy[m]> i think the preferred / more secure way would be to have a view-key wallet on the server 
14:57:16 <cryptogrampy[m]> and the spend stuff only can happen in the mobile wallet
14:57:20 <cryptogrampy[m]> er, it's initiated there
14:57:40 <cryptogrampy[m]> or maybe split between the two somehow (i think someone was discussing this)
14:57:59 <r4v3r23[m]> so you'd have  to use rpc with your own/trusted node
14:58:05 <cryptogrampy[m]> correct
14:58:08 <cryptogrampy[m]> well,
14:58:15 <cryptogrampy[m]> you could use whatever node you want i guess
14:58:36 <cryptogrampy[m]> but if you're already going through the trouble of running wallet-rpc, you may as well be running your own node
14:58:57 <cryptogrampy[m]> i think another advantage of wallet-rpc wallets is encouraging users to run their own node
14:59:02 <r4v3r23[m]> so "traditional" would be the way to go for most users on mobile
14:59:09 <cryptogrampy[m]> you want instant sync?  here, run your own node
14:59:39 <cryptogrampy[m]> i think a wallet that syncs on a server is much better for users on mobile.  low bandwidth, instant sync
14:59:39 <r4v3r23[m]> maybe a hybrid then
14:59:59 <cryptogrampy[m]> a hybrid would be interesting for a situation where your server goes down 
15:00:16 <cryptogrampy[m]> i think the mvp though would be a wallet that just runs using wallet-rpc
15:00:48 <cryptogrampy[m]> being able to run the wallet in 'traditional' mode would be a feature
15:00:57 <r4v3r23[m]> standard mode and "own node" mode
15:01:11 <cryptogrampy[m]> https://github.com/woodser/monerowebwallet.com
15:01:37 <cryptogrampy[m]> https://github.com/monero-project/monero/pull/8110
15:02:28 <r4v3r23[m]> im not quite understanding the difference
15:02:37 <r4v3r23[m]> besides insta-sync
15:02:47 <r4v3r23[m]> and how that would differ from an lws server wallet
15:02:53 <cryptogrampy[m]> https://github.com/hyahatiph-labs/infosec/tree/main/himitsu
15:03:04 <cryptogrampy[m]> apparently this works with android 
15:03:09 <ofrnxmr[m]> cryptogrampy[m]: Monero rpc and cli work together 
15:03:23 <ofrnxmr[m]> So ideally, id like my wallet to continue syncing using rpc in the background, and switch to cli when I open it
15:03:34 <cryptogrampy[m]> r4v3r23[m]: they're very similar, but LWS can support multi-users
15:03:38 <r4v3r23[m]> ofrnxmr[m]: or just use lws
15:03:40 <cryptogrampy[m]> but LWS doesn't have subaddress support
15:03:41 <r4v3r23[m]> yeah?
15:03:59 <r4v3r23[m]> isnt that being worked on?
15:04:12 <ofrnxmr[m]> r4v3r23[m]: Lws would be ideal 
15:04:34 <ofrnxmr[m]> But. ... realistically, if I have access to the wallet file in Cale wallet, I can, right now, use rpc to keep my wallet in sync
15:06:28 <cryptogrampy[m]> tough to say what the right answer is.  i think wallet-rpc allows you to do a lot more admin type stuff remotely, but LWS requires you to log into your server to do admin management stuff. 
15:06:34 <cryptogrampy[m]> there's no admin api for LWS
15:06:43 <cryptogrampy[m]> s/api/RPC/
15:06:54 <ofrnxmr[m]> Have to add view keys manually, no? 
15:07:22 <cryptogrampy[m]> you make a request to the server like 'please start scanning primary key and view key'
15:07:32 <cryptogrampy[m]> and then you log into the server, say admin list-requests
15:07:44 <ofrnxmr[m]> Ah, your bug on mymonero 
15:07:45 <cryptogrampy[m]> you see the request for access, then you do admin accept-request
15:07:56 <ofrnxmr[m]> Not working for me because it wont connect to create the wallet 
15:07:59 <cryptogrampy[m]> you can't do this from client side
15:08:19 <cryptogrampy[m]> ofrnxmr[m]: hopefully they merge my fix
15:08:32 <ofrnxmr[m]> Yeah.. hopefully lol.
15:08:54 <cryptogrampy[m]> i think wallet-rpc is probably the right direction for the next couple years
15:09:16 <cryptogrampy[m]> lws needs admin tools, subaddress support, and realistically limited view keys 
15:09:43 <cryptogrampy[m]> it also has a fingerprinting problem
15:10:01 <cryptogrampy[m]> lws tx's are easier to fingerprint (apparently) 
15:10:13 <ofrnxmr[m]> Yeah, using a different decoy algo
15:10:13 <ofrnxmr[m]> But right now it should be the same. Not sure about post hf
15:10:58 <cryptogrampy[m]> to the end user, an rpc wallet would probably be no different than mymonero
15:11:05 <cryptogrampy[m]> in terms of sync time/usability
15:11:17 <ofrnxmr[m]> But yeah.. cli created encrypted wallet files. Cake and monerujo dont store them in public storage, so my idea of using rpc in the background doesnt work
15:11:33 <cryptogrampy[m]> but rpc has subaddresses today and that's good, and it will likely have support for big changes in teh future
15:16:49 <cryptogrampy[m]> Another thing I'm not sure on with wallet-rpc is the http digest auth... how secure is that/is there something better?
15:19:02 <ofrnxmr[m]> Using self signed ssl certs easy to mitm but you can probably onion it?
15:20:07 <r4v3r23[m]> <ofrnxmr[m]> "But. ... realistically, if I..." <- so RPC would be for syncing only. nothing else
15:20:37 <ofrnxmr[m]> Yeah
15:21:17 <r4v3r23[m]> <ofrnxmr[m]> "But yeah.. cli created encrypted..." <- background sync is being worked on by [jberman](https://matrix.to/#/%40jberman%3Amatrix.org)
15:22:04 <ofrnxmr[m]> For which? CLI, cake, rujo?
15:22:17 <ofrnxmr[m]> I saw PRs on rujo
15:22:24 <cryptogrampy[m]> you can do a client side rpc wallet with monero-javascript
15:22:58 <r4v3r23[m]> <cryptogrampy[m]> "tough to say what the right..." <- there's a UX balance, especially on mobile. i think the type of user that would want to do admin shit would just do it on the node directly instead of their spending wallet
15:23:17 * cryptogrampy[m] uploaded an image: (337KiB) < https://libera.ems.host/_matrix/media/r0/download/monero.social/FvJnjCicWQPQEHnrknjOJhde/image.png >
15:23:37 <r4v3r23[m]> ofrnxmr[m]: he was working on it for rujo but it can apply to all wallets i guess
15:23:56 <r4v3r23[m]> i think m2049r even asked for it to be a core wallet feature instead of rujo specific
15:24:00 <cryptogrampy[m]> r4v3r23[m]: link?
15:25:55 <r4v3r23[m]> https://github.com/m2049r/xmrwallet/issues/785
15:26:31 <r4v3r23[m]> keep view-key hot on device that loads synced blocks when you open wallet
15:26:49 <r4v3r23[m]> same UX as lws/rpc, but syncing happens locally
15:52:06 <bridgerton[m]> <joshhavepigdog> And this would work as a preventive measure from the chain getting to Terabytes in size prior to 2030?
15:54:36 <bridgerton[m]> <joshhavepigdog> In practice if you had to guess, let’s say we were getting crazy mass adoption 4 years from now, what is the practical limit on how large the chain would expand per year or prior to year 2030? If you had to give a rough ball estimate.
16:19:26 <r4v3r23[m]> 42
18:14:39 <ArticMine[m]> The adaptive block size has been part of Monero since its inception. A Bitcoin type hard cap would be a very serious violation of Monero's social covenant. I actually sold my Bitcoin for Monero over this issue. Over 99% in 2014 and 2015. The balance in 2017. 
18:14:39 <ArticMine[m]> By the way 1 MB in 2009 when Bitcoin was launched is equivalent to over 200 MB today. 
18:16:08 <sech1> equivalent by network bandwidth or HDD capacity?
18:16:29 <sech1> I don't think HDDs got 200 times larger
18:18:34 <ArticMine[m]> Network bandwidth
18:19:34 <ArticMine[m]> One can add storage, but not bandwidth. 
18:20:25 <ArticMine[m]> Ethereum is over 10 TB today 
18:20:42 <sech1> and almost no one runs full ETH node
18:21:09 <sech1> the good benchmark is the latest Call of Duty download size
18:21:15 <sech1> blockchain shouldn't get above that :D
18:22:19 <ArticMine[m]> A proprietary game. Seriously 
18:22:27 <sech1> https://www.reddit.com/r/Monero/comments/tnm7kk/monero_full_node_size_vs_aaa_video_game/
18:22:37 <sech1> that wasn't serious, but still :D
18:23:31 <sech1> A proprietary game knows well what the average user can afford in terms of storage/bandwidth
18:23:54 <bridgerton[m]> <joshhavepigdog> I’m not worried about bandwidth. I’ll take your word for it if you say storage isn’t an issue though. I just futures end users aren’t going to have 10 TB drives to store Monero’s chain on, but could be wrong about this.
18:24:21 <bridgerton[m]> <joshhavepigdog> I’m not worried about bandwidth. I’ll take your word for it if you say storage isn’t an issue though. I just wonder if future end users are actually going to have 10 TB drives to store Monero’s chain on?
18:24:30 <ArticMine[m]> I recently bought a 8 TB ssd
18:24:42 <bridgerton[m]> <joshhavepigdog> How much was it?
18:25:09 <ArticMine[m]> 1100 CAD
18:26:23 <ArticMine[m]> 4 TB is the optimal Ballpark 100 USD / TB
18:27:10 <ArticMine[m]> I see little justification to cripple Monero over this 
18:29:11 <ArticMine[m]> One has also to look at long term trends, to eliminate short term noise like the aftermath of COVID
18:34:44 <bridgerton[m]> <joshhavepigdog> Gotcha. $850 bucks for 8TB SSD isn’t so bad. You’d basically need an SSD over and HDD though in order for a big blockchain like that download quick enough though right?
18:59:14 <nioc> you have basically needed an SSD for monero for a while because HDDs suck and random R/W
19:00:17 <bridgerton[m]> <joshhavepigdog> Got it. Thanks for the reply, I’ll keep it in mind not to sync the chain to an HDD, and use an SSD instead 🙂
19:31:20 <ArticMine[m]> For large over 10 TB HDDs do work for Monero once the chain is synched. Syncing is still slow. though. HDDs under 1 TB really suck for Monero 
19:32:15 <ArticMine[m]> Realistically do Monero it is SSD
19:32:31 <CidadoisAncap[m]> Speaking of syncing, why does it take so long for my cake wallet to sync?
19:32:56 <CidadoisAncap[m]> Is it my internet conection or the is overall network slow?
19:40:04 <nikg83[m]> <CidadoisAncap[m]> "Is it my internet conection or..." <- Your connection to remote node being used 
19:41:08 <nioc> .shrug, syncing seems fast to me
19:42:25 <plowsof> after hardfork up to 40% faster :$ 
19:42:34 <CidadoisAncap[m]> Could someone indicate a fast remote node?
19:42:40 <plowsof> selsta2.featherwallet.net:18081
19:44:16 <CidadoisAncap[m]> Deus é bom
19:47:57 <selsta> plowsof: 40% with local node
19:48:12 <selsta> the problem is with remote node other delays could slow things down, we will see
19:48:42 <plowsof> oh thanks for clarifying, i was not aware of the caveat 
19:51:09 <selsta> it should still speed things up
19:51:26 <selsta> but if you are bottlenecked by something else it might not be 40%
20:30:23 <ArticMine[m]> They dropped the price on that 8 TB SSD I bought. It is 900 CAD . With the taxes in BC 1008 CAD Newegg.ca 
20:40:28 <ArticMine[m]> One thing I have learned about this is that the goalposts keep moving while the conversation is going on. 
20:40:28 <ArticMine[m]> As for HDDs it is 20x since 2009. HDDs are a very mature technology going back to the 1950s. I expect the big moves in the coming years will be in SSDs SUDC nand memory etc 
20:56:37 <bridgerton[m]> <joshhavepigdog> I didn’t realize SSD’s that are huge like that are already that inexpensive (in my opinion). Tis a small price to pay to secure Monero. 
20:56:38 <bridgerton[m]> All you have to do when downloading the chain to an external SSD is direct it to be stored there, rather than to the laptop that the external SSD is plugged into, correct?
20:57:03 <bridgerton[m]> <joshhavepigdog> And Monero’s total chain size right now is about 0.2 TB right?
21:01:44 <nioc> I am using a 240GB SSD which is ok for now (bought it years ago) 
21:02:05 <nioc> it is full chain and if pruned will last years more
21:02:27 <nioc> size is not much of an issue 
21:03:16 <jberman[m]> <r4v3r23[m]> "he was working on it for rujo..." <- implemented it in the core repo so it can be used by all wallets. just needs final touches: https://github.com/j-berman/monero/commit/238ea538f218ad447808c6806386a73bb1ab0fd5
21:03:16 <jberman[m]> I was getting familiar with monerujo to understand how/where it would be used there + to test end-to-end
21:12:22 <bridgerton[m]> <joshhavepigdog> Gotcha. Thanks.
23:46:32 <escapethe3ra[m]> https://monero.observer/btcpayserver-1.6.1-release-fixes-critical-bug-altcoins-integration/