05:37:07 <BusyBoredom[m]> It looks like there is currently no autoformatting or linting in monero codebase's CI, is that true or am I missing it?
05:37:07 <BusyBoredom[m]> Asking 'cause I've been playing around with code stylometry lately, and a lack of formatting/linting in CI might make the monero codebase a really good candidate for it.
14:26:51 <caveman> i hope this is the right place to discuss this:  i'm increasingly sickened by how MMT/keynesian economics steals our money.  i'm all for paying for services that we use, but the way governments take our money for them is very shady (taxation is a bad idea; we should rather have service/goods fees).
14:27:47 <caveman> however, unfortunately, i'm also disappointed that all cryptocurrencies seem to require a permanent network infrastructure, such as the internet.  this makes them very easy to regulate by governments who have enough power to control any permanent structure physically.
14:27:54 <llacqie[m]> Non-dev questions -> #monero, please
14:28:17 <caveman> ok.  apologies.
15:08:04 <xfedex[m]> There's an issue with monerod which slows down syncing.
15:08:04 <xfedex[m]> If I try to sync monerod on an hard drive, it says "1 month remaining". By looking at task manager, it appears that monerod writes to the hard drive ~5x more data than needed - if I start monerod and wait until the database size is ~100MB, it has written ~500MB.
15:08:04 <xfedex[m]> On an SSD, syncing is much faster however it still writes ~5x more data than the database size.
15:13:02 <moneromoooo> Play with --db-mode as per https://github.com/monero-project/monero/issues/8189
15:19:07 <xfedex[m]> <moneromoooo> "Play with --db-mode as per https..." <- By default --db-mode appears to be `fast:async:250000000bytes`, shouldn't this be enough for a fast synchronization?
15:25:11 <moneromoooo> Try the suggestion in the thread and find out.
15:27:35 <moneromoooo> Median block weight seems to be about 25 kB. So 250000000bytes is about 10k blocks, so 1% of the suggestion in that thread,
15:27:54 <moneromoooo> (I think, and I'm using median, not average)
15:28:45 <moneromoooo> Average 18 tx/blxk
15:29:07 <moneromoooo> Average 18 tx/block, so average block size is likely a bit below 30 kB, close enough.
15:32:47 <caveman> i'd like to discuss a totally different protocol than monero's.  is this the right channel?
15:33:54 <caveman> #monero is certainly not suitable.  too high noise.
15:34:18 <moneromoooo> If it is with a view to implement it in monero, possibly. This channel is for monero development.
15:34:27 <moneromoooo> implementing
15:34:46 <moneromoooo> If it's pie in the sky stuff, possibly not.
15:35:16 <moneromoooo> If unsure, try it and see.
15:35:19 <caveman> basically, i'd like the protocol to be delay-tolerant, so that it can operate in store-and-forward style.
15:35:43 <caveman> and by delay i mean, possibly months or a year.
15:36:09 <moneromoooo> It seems hard for an output based system.
15:36:41 <caveman> output-based system?
15:36:59 <moneromoooo> Actually, while continuing writing, I find it's also hard for a balance based system...
15:37:23 <moneromoooo> I mean based on outputs ("coins"), like monero and botcoin.
15:37:27 <moneromoooo> bitcoin
15:37:53 <caveman> what's an output-based system?
15:38:34 <moneromoooo> If you have N monero and want to use them in a system where a tx can be delayed months, you have to (among other things) deal with you sending two txes that double spend each other.
15:39:00 <moneromoooo> An output based system is one based on outputs ("coins"), like monero and bitcoin.
15:39:55 <moneromoooo> A possible way to deal with this is to add metadata to outputs saying "do not consider any output created from spending this output to be received before N blocks".
15:40:47 <moneromoooo> Then if you (Alice) spend the same output to Bob and Carol, who won't be able to see the chain for months, they'll have to delay acting on the payment for that much.
15:40:55 <monerobull[m]1> <caveman> "and by delay i mean, possibly..." <- You could send transactions in a delayed network a wallet and then drain the wallet the on the up-to-date network, making the transactions on the delayed network invalid
15:41:02 <caveman> moneromoooo: where N is enough blocks to have enough confidence that it has reached everywhere including regions separated by months?
15:41:04 <moneromoooo> It's kinda useless though. so you need better. And I don't see how it can be made better.
15:41:10 <monerobull[m]1> * You could send transactions in a delayed network from a wallet and then drain the wallet the on the up-to-date network, making the transactions on the delayed network invalid
15:41:25 <moneromoooo> There's also the opendime system, if you trust it to stay "hard" to defeat.
15:41:27 <monerobull[m]1> * You could send transactions in a delayed network from a wallet and then drain the wallet on the up-to-date network, making the transactions on the delayed network invalid
15:41:27 <xfedex[m]> caveman: A system based on UTXOs, like Bitcoin, Litecoin, Monero, and many others.
15:41:27 <xfedex[m]> Ethereum uses account-based system instead of UTXOs
15:42:12 <moneromoooo> Opendime requires physical exchange though, so niche/special case.
15:43:49 <moneromoooo> I feel the requirements are similar to distributed databases. There are different models of ensuring consistency.
15:44:37 <moneromoooo> I don't know this space though. But PoW + longest valid chain with reorgs is the canonical way of cryptocurrencies to ensure consistency.
15:45:06 <moneromoooo> Maybe there are other ideas from the DB space which could help better this.
15:47:40 <moneromoooo> Thinking about it, I have a possible start of an idea, though it does seem limited to rich people:
15:49:14 <moneromoooo> On a balance based system, you could mark your account (with starting balance B) as being able to spend only with a tx proof work, the target of which would be dependent on the ratio between the amount sent to B.
15:50:01 <moneromoooo> This means that you can't spam double spends because you'd end up with having to do way too much PoW for those txes to be valid.
15:50:34 <moneromoooo> The con is that in order for the PoW to be practical to perform for a tx, you'd have to send a small fraction of B.
15:50:44 <moneromoooo> It'd be probabilistic only though. So probably not safe.
15:52:26 <moneromoooo> Then again, if it's opt-in (ie, you have to mark your account as being usable offline like this), the PoW can be made pretty heavy, so you'd accept having to wait a few hours for a tx from a phone...
15:52:56 <moneromoooo> It also means more energy expenditure, which is not ideal.
15:53:30 <moneromoooo> It also means compromised privacy, since you have to mark an account.
15:55:45 <moneromoooo> I suppose it could maybe be made somewhat more private, by marking an output, making a range proof to prove its value is more than, say, 100 times the value of the new output created. Though how to differentiate between amount sent and change may not be easy.
15:56:14 <moneromoooo> Privacy makes a lot of things harder unfortunately :/
15:57:01 <moneromoooo> Anyway, all very handwavy I'm afraid...
15:58:57 <caveman> interesting (making individuals pow their transactions in account-based systems).
16:14:00 <caveman> moneromoooo: i have a very different approach, but totally blows privacy out of the window.  it goes like this:  let people endorse each other up to certain limits.  the endorsements will be based on security guarantees that is frozen for long enough (e.g. years).  let double spending possibly happen, but impose a hefty punishment once it gets discovered.
16:14:39 <caveman> in order for an endorsement to be meaningful, one would have to build a good reputation until people recognise him as a trusty individual.  this in a sense is a kind of PoW, except that the work done is building a good reputation.  
16:15:31 <moneromoooo> Is it basically trust, or is the punishment the loss of some money that cannot otherwise be spent before the double spend can be detected ?
16:15:40 <moneromoooo> (or other ?)
16:16:02 <caveman> people that are recognised as trusty individuals, they can effectively act like banks in that they endorse other people up to certain limits (e.g. guarantee their payments up to some amounts).  in order for such endorsers to not lose the trust of the network, they will evolve to require certain guarantees from the people that they endorse (some may require physical deposits or knowing their
16:16:05 <caveman> locations ,etc).
16:16:39 <moneromoooo> Sounds like you don't need a chain then :)
16:17:02 <caveman> it's both.  except that the punishment is left to the endorsers to figure out, each based on what works best for them.  the network will only care about the whether someone is violating the rules, and if so that entity will be no longer trusted.
16:17:12 <caveman> yeah.  possibly without a chain
16:28:31 <caveman> essentially, this approach would be identical to the current fiat system, except for that no one can issue currency out of thin air, and that there is no central authority on who can become a bank (endorser)
16:41:13 <caveman> the nice thing is that it will be super fast to send payments (since it's delay tolerant; no requirement of syncing prior to confirmations).
16:41:25 <caveman> also, solves the key problem with fiat:  inflation/deflation by central bank.
16:41:48 <caveman> (i.e. printing new fiats out of thin air will be gone)
16:42:46 <caveman> oh-and:  doesn't require internet.  people can communicate by whaterver hop-by-hop mechanism, such as bluetooth, nfc, etc.
17:08:42 <caveman> i think the future currency that will replace fiat (and central banks) is of this kind.
17:30:31 <UkoeHB> Without a source of truth it is trivial to inflate the supply
17:32:36 <caveman> here, truth source is the overall population that uses the currency.  as they will decide whom to trust.
17:33:22 <caveman> there can be an origin/genesis block that defines all coins available.  so this is a truth source for limiting the supply.
17:43:51 <UkoeHB> one failed trust connection and the entire system collapses
17:46:04 <caveman> the genesis?  yes.  but how is it for the other?
17:46:53 <caveman> the 2nd trust (people accepting transactions) is done by individuals as they other hierarchies.
18:28:02 <fr33_yourself[m]> <UkoeHB> "Without a source of truth it..." <- agree
21:23:54 <caveman> UkoeHB: what makes a thing a source of truth in your view?  e.g. what requirements do you seek?  
21:31:47 * afungible[m] uploaded an image: (46KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/QjIWzgtnXcyOCxmjvUNAqfAX/Screenshot_20221224-223016.png >
21:34:25 <afungible[m]> On Monero v0.18.1, If we have a wallet like this, e g. 3 sub-address outputs with v.low balance and 4th sub-address with enough balance, to combine outputs with sweep_all, doesn't work. It so happened, that I raised this before & was seemed to work, not sure why it doesn't work anymore.
21:53:39 <selsta> afungible[m]: do you know the exact version that broke this?
21:56:30 <UkoeHB> caveman: unambiguous, static rules
21:57:31 <UkoeHB> that resolve disagreement trivially
21:59:09 <afungible[m]> <selsta> "afungible: do you know the exact..." <- I raised this & debugged this in detail with moneromoo, but on a version pre-hardfork, so 0.17 stable.
21:59:09 <afungible[m]> https://github.com/monero-project/monero/issues/8480
21:59:09 <afungible[m]> Apparently, don't see it working on 0.18.1. Someone must confirm as well.
22:02:46 <afungible[m]> The title of the PR was modified after sweep_all for all indices was tested to work, but that was then.