01:14:58 * nikg83[m] uploaded an image: (555KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/zGTDMDBUPjTjbhUipkGVsPcU/ima_5fbaeca.jpeg >
01:23:59 <nikg83[m]> <nikg83[m]> "ima_5fbaeca.jpeg" <- next fork reduce selection of %  recently made decoys should be done + bump in fees to make spam attack expensive 
01:23:59 <nikg83[m]> Also maybe make nodes a bit smarter to slow (not block) down this spam by analyzing if some IPs are broadcasting too many txs , also remote nodes can slow them down if they are being used to broadcast this spam attack
01:28:32 <selsta> your second suggestion won't work
01:29:58 <nikg83[m]> selsta: Yah, maybe nodes need to analyse txs too like how they are constructed 
01:30:09 <selsta> won't work
01:30:26 <selsta> there is nothing that makes a tx "spam" compared to other tx
01:33:01 <selsta> fees will get bumped by 5x
01:35:48 <selsta> "next fork reduce selection of %  recently made decoys" <-- decoy selection is based off the Moser et al. paper, it's not a good idea to arbitrarily change, it possibly worsens privacy
01:35:59 <selsta> Rucknium[m] will most likely research that
01:42:25 <nikg83[m]> <selsta> "fees will get bumped by 5x" <- 2cents for 2/2 at current xmrusd value is still cheap
01:47:57 <selsta> I would like them a bit higher too
02:01:07 <nikg83[m]> Btc avg fee is 2usd, we aren’t going to 100x (or even 10x) anytime soon that we have set such low fee 😅 
02:01:07 <nikg83[m]> I think we need a public vote to know what fee users feel like comfortable paying for private transactions 
02:01:07 <nikg83[m]> If xmrusd prices do increase at some point and fees do look huge, our planned hf in future can lower it down like we are doing right now to increase it 
02:17:12 <gingeropolous> i still think we should find a way to use the difficulty as a corollary to the meatworld price, well the velocity of the difficulty - the rate of change.
02:18:38 <gingeropolous> well, the velocity would be part of it. basically you'd have to find a way demultiplex the effect of hardware efficiency increases
04:55:05 <monerobull[m]> Many people didn't like how the transaction flood attack only costed 1k usd to add over 500 mb to the chain. Higher fees would help a little bit.
06:07:14 <mj-xmr[m]> <monerobull[m]> "Many people didn't like how..." <- How about exponentially increasing fees from one address within a period of time, after which they'd start to exponentially decay?
06:08:50 <minthos> wouldn't that just force the attackers to be a little more sophisticated and spread the coins out to a bunch of addresses first?
06:24:50 <spirobel[m]> <minthos> "wouldn't that just force the..." <- there is another variable here: minimum transaction amount. also transaction fee in relation to transaction amount. we get a little bit into the visa 2% percent per charge territory with this kind of thinking....so got to be careful.. not to overstep
06:28:30 <komikono[m]> would a fee based on average utxo age be more feasible? would make flooding,although for everyone, more costly but not affect the "normal" fees
06:34:43 <mj-xmr[m]> <minthos> "wouldn't that just force the..." <- I thought about that too. Yes. Very possible.
06:43:30 <spirobel[m]> maybe a minimum transaction amount is the most effective way against transaction flooding. while minimally impacting normal users. It forces the attacker to hold large amount of xmr to carry out the attack. much easier to have 1k than have access to  1M
06:46:07 <Inge> monerobull: In monero, you don't know the origin address ...
06:48:38 <mj-xmr[m]> Inge: Sure, but I thought the wallet software could help with that. OTOH, it would break privacy and it could still be avoided with tailored version of the wallet.
06:48:56 <mj-xmr[m]> <spirobel[m]> "maybe a minimum transaction..." <- So I think this is the best we could think of...
06:49:27 <mj-xmr[m]> although this will totally kill people in poorer countries.
07:03:47 <minthos> gingeropolous: hardware efficiency increases can be seen as a proxy for humanity's productivity growth, where energy is the universe's scarce resource and compute cycles are what we produce from it. Deflation in the energy cost of compute cycles is a given as long as technology continues to progress.
07:05:09 <minthos> the usd is meaningless in that context, though of course it has immediate meaning for people here on earth who have to buy energy for their human bodies
08:25:37 <spirobel[m]> <mj-xmr[m]> "although this will totally..." <- i dont think so. monero is not really suitable for microtransactions anyway. microtransactions need to happen fast and have practically 0 transaction cost. So this will always happen off chain anyway. poor people != microtransactions. The main benefit of monero for people from poor countries is that they can create digital products and sell them world wide. So the removal of borders and
08:25:37 <spirobel[m]> defense against their tyrannical rent extracting governments is the real use case here. 
08:26:14 <mj-xmr[m]> OK, I get you.
08:33:02 <merope> Raising the minimum amount makes no sense imo. If someone is rich and determined enough to do a spam attack, they won't care much about the minimum amount
08:33:35 <merope> Besides, the main bottleneck to such an attack would be the number of inputs available in the wallet, not their actual value
08:34:07 <merope> And creating a minimum amount at the protocol level would have several other issues:
08:35:18 <merope> - it would effectively render all the other digits to the right completely useless: why have 12 decimal places, when you can only use eg 6?
08:36:41 <merope> - it would create issues in case of price swings: if the price goes up, then that minimum amount might be too high for regular users; conversely, if it goes down, you would have to raise the minimum tx amount *at the protocol level* again, which is not sustainable
08:37:21 <merope> - you cannot tie the minimum tx amount to any other external currency nor the price, because it would basically be a massive vulnerability
08:37:24 <atomfried[m]> yeah i also think someone who is stoped by paying 10k more for an attack isnt a real danger to begin with
08:37:33 <merope> ^
08:39:29 <merope> - microtransactions *are* suitable for Monero. 0conf and 1conf transactions are actively used *today* by some services, and there's no reason why we should prevent people from doing them
08:41:10 <merope> - unless you set the minimum limit to something really high (which would make the currency unusable for small transactions), you're not really putting a dent into an attacker's ability to perform the attack; and if your limit is too low, then you've added a useless restriction for no reason anyway
08:42:53 <sech1> how do you even implement minimum tx amount if amounts are hidden. Also, this is more suitable for #monero. This channels is a dev-only
08:43:57 <spirobel[m]> <merope> "- you cannot tie the minimum..." <- you could tie it to the transaction fee. make it a multiple of the transaction fee. even 0conf microtransactions dont make sense at such a low level. If someone is paying a 10% transaction fee or even a crazy 100% or even 1000% transaction fee you are probably not dealing with a rational market participant, but with an attacker. So they need to wait until they can reuse the funds
09:16:14 <moneromooo> You can have a minimum amount per output, using range proofs.
09:16:49 <moneromooo> However, it might be annoying with change (ie, min is 10, you have 17, want to pay 10, can't (or burn the 7)).
09:17:34 <moneromooo> You can't bump fees for subsequent txes from the same address, other nodes can't tell where inputs are from, even if all rings were 1 sized.
09:19:12 <moneromooo> A good reason to push back aganst microtransactions is to avoid spam. Nobody (well, me) wants to have millions of those littering the chain forever.
09:39:15 <sech1> fee increase will indirectly fix microtransactions
09:40:07 <mj-xmr[m]> <moneromooo> "A good reason to push back..." <- How about 1 complete blockchain for normal transactions and another one, 1 year long max, automatically prunable, for µtransactions?
09:45:55 <mj-xmr[m]> It it's silly, just don't say a thing :)
09:47:04 <moneromooo> I hope it's not silly, it's what I've been wanting to do for years.
09:50:22 <mj-xmr[m]> I think that if a group agrees on "one size fits all", there will be always acts of rope-pulling in either direction.
09:53:35 <anarkiocrypto[m]> Deposit Monero onto the microtransaction sidechain, do the microtransactions, then the vendor withdraws their earnings onto the mainchain, similar to Bitcoin <-> Bitcoin Lightning?
09:53:35 <anarkiocrypto[m]> It's nice to make small transactions with Monero, e.g. a $5 VPS payment, or in the future, maybe a $2 public transit ticket or $1 coffee. Especially as banking, credit cards, Paypal, Apple Pay, etc. are inaccessible due to KYC and cash is sadly being phased out, we need something that is private and financially accessible for small payments too.
09:54:25 <anarkiocrypto[m]> s/accessible/inclusive/
09:55:16 <moneromooo> The one I was thinking about is: every 4 months, start a new chain. Atomic swaps between any of those and/or monero. Each such chain lasts a year, any money left on it is burnt. Low fees on those chains, high fees on main chain.
09:56:19 <moneromooo> So if you want to do frequent trades/microtransactions/etc, you move your money once, and all the stuff you do on those chains will disappear after a year. Any balance can be moved to next cnain (there's a healty time overlap) or main chain.
09:56:32 <moneromooo> But you're incentivized to stay on the side ones due to low fees.
09:56:40 <moneromooo> Or rather, high fees on the main chain.
09:58:19 <kayabaNerve> moneromooo: That will be subject to market conditions which makes it not feasible
09:58:25 <moneromooo> The fact each remaining output on side chains is burnt after a year is what enables the total dumpage of the data.
09:59:03 <kayabaNerve> Not to mention the initial supply needs to be held by someone to trade away
09:59:05 <moneromooo> kayabaNerve: what does that mean ? :)
09:59:23 <anarkiocrypto[m]> > any money left on it is burnt
09:59:23 <anarkiocrypto[m]> Allowing people to lose money is risky... especially for people who don't know about the updates, didn't know they received funds, take a long time to update, stored it as emergency funds, or want to save/hodl their funds. Lost money can mean they are unable to buy food, pay rent, use their emergency savings, etc. There should be a way to restore the old funds somehow.
09:59:23 <anarkiocrypto[m]> Atomic swaps is a good technical solution for mainchain <-> sidechain.
09:59:23 <moneromooo> (the market condition sentence)
09:59:29 <kayabaNerve> People won't swap if the chain isn't used. No one buys the alt chain's XMR, its value is 0.
09:59:51 <kayabaNerve> Not to mention the alt starts with 0. There's nothing to be swapped for
10:00:04 <kayabaNerve> Unless you're handing your XMR to whoever started it and expecting them to buy back
10:00:26 <kayabaNerve> This is something for MPC, not atomic swaps, unless you're exchanging against the standing pool which was established via MPC
10:01:10 <moneromooo> I did not mena use another cryptocurrency.
10:01:12 <anarkiocrypto[m]> Bitcoin and Bitcoin Lightning are 1:1. AFAIK, you spend/lock Bitcoin to get Lightning BTC and can withdraw/unlock this Lightning BTC for Bitcoin. You can't mine it from nothing.
10:01:13 <kayabaNerve> Or XMR itself is forked for parachains
10:01:20 <anarkiocrypto[m]> Monero and its sidechain could be similar.
10:01:26 <kayabaNerve> No, you meant something pegged. Atomic swaps can't maintain pegs
10:01:28 <kayabaNerve> Market conditions
10:01:49 <moneromooo> You just burn N monero in one of the chains, and N monero pop up in your chosen other.
10:01:59 <kayabaNerve> Atomic swaps can't do that. You want MPC
10:02:09 <moneromooo> Similar to what happens in Townforge when you deposit/withdraw to/from game.
10:03:01 <moneromooo> Same currency, just two "places" it's accounted.
10:03:13 <kayabaNerve> I can explain more in ~10 minutes
10:03:45 <moneromooo> I might have used "atomic swaps" in a vague sense, sorry about that :D
10:04:09 <moneromooo> I did not you mean your actual protocol. Just in the sense that money moves atomically between the chains.
10:05:49 <kayabaNerve> XMR would have to be forked for sidechains or you're back to MPC :p
10:06:56 <moneromooo> I did not see that as a problem.
10:07:36 <moneromooo> It'd be... kinda one chain... but N chains... 
10:07:57 <moneromooo> More like... one chain, but N distinct sets of outputs that cannot interact except via the "move" command.
10:24:58 <Halver[m]> what does MPC stand for ? 🙏
10:29:19 <moneromooo> Multi party computation.
10:35:25 <carrington[m]> If there could be some similar system of moving windows on the main chain that would be excellent. It would have to have some mechanism to force a self-spend at a certain block height to keep outputs "fresh". This would also serve as an automatic churning mechanism. It would solve the issue of blockchain bloat.
10:35:25 <carrington[m]> It would also lower the impact of "suspiciously old" ringmembers because there would be a much shorter tail to the spend distribution.
10:35:25 <carrington[m]> There are probably some fundamental flaws with the whole idea though.
10:38:58 <moneromooo> The point of the multiple "chains" is that it's optional. You only have to move or lose your coins if you chose to do that in the first place.
10:39:40 <moneromooo> ie, someone who mined monero in 2014 and will only come back in 2050 will still have them.
10:39:47 <carrington[m]> Does it matter if a self spend is forced? 
10:40:39 <moneromooo> I don't even understand the question.
10:41:05 <carrington[m]> Obviously such a system would not be backwards compatible though
10:44:59 <carrington[m]> It you have some system which forces a self spend (in order to keep outputs fresh and allow deletion of older blocks), then there is no risk of losing the coins so it doesn't matter that it is not optional
10:50:29 <mj-xmr[m]> > <@anarkiocrypto:halogen.city> > any money left on it is burnt... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/2bf20dabd6c56a2aaac1f0aa76c171fbcfe2185b)
10:54:16 <anarkiocrypto[m]> Losing a physical wallet is your fault. Someone deleting a blockchain that contains your money is not your fault.
10:54:17 <anarkiocrypto[m]> At least store the old blockchains somewhere, even if they aren't used by nodes anymore. Then people could maybe recover their funds for a fee.
10:55:59 <anarkiocrypto[m]> > It would have to have some mechanism to force a self-spend at a certain block height to keep outputs "fresh".
10:55:59 <anarkiocrypto[m]> This wouldn't work for paper wallets, or someone who is hodling/saving, or someone who keeps Monero as emergency funds (many vital real life use cases for this) and doesn't check their wallet often.
10:58:08 <carrington[m]> It would be a self spend so the paper wallet user would still recover their funds. 
10:58:31 <kayabaNerve> moneromooo: I personally hate MPC yet ack its value here. Idea. Have the MPC participants claim all funds left on the chain, beyond TX fees. Could be used to start a bidding war ensuring all validators have enough at risk to be validating. The issue is they need to be over collateralized for that to work. That's why increased profit incentives are valuable.
10:58:36 <anarkiocrypto[m]> Blockchains are designed to be based on the genesis block and all blocks that were mined after it. The point of blockchain is to have a single secure confirmed history of spends. You shouldn't permanently delete blocks. Pruning is OK as long as there are still full nodes. Maybe checkpoints or archiving some old blocks could be OK, if there is a guaranteed way to restore funds from archived blocks. But don't delete them.
10:58:51 <anarkiocrypto[m]> Paper wallet can't self spend or make any TXs, since it isn't connected to the internet or any wallet.
10:58:59 <anarkiocrypto[m]> It's just a mnemonic on a piece of paper.
11:00:19 <moneromooo> kayabaNerve: sorry, I don't know enough to tell what it is you are proposing.
11:00:49 <kayabaNerve> You proposed funds left on the chain die. I propose they go to the participants in the MPC, if a MPC is used, but I much rather shard Monero in general. MPCs are garbage.
11:01:29 <moneromooo> You mean a scavenger thing ? Anything that wasn't moved is free for the taking ?
11:01:49 <kayabaNerve> Not by anyone. By the MPC
11:02:00 <moneromooo> Who is the MPC ?
11:02:05 <kayabaNerve> It increases their profit incentive which needs to be high if they're to over collateralize the chain to ensure they don't run off
11:02:27 <kayabaNerve> I don't have all the answers :p
11:02:27 <moneromooo> And why do they need a profit incentive ?
11:02:36 <kayabaNerve> So they don't steal all the XMR
11:02:37 <moneromooo> I feel like we're talking about two different things here...
11:02:57 <kayabaNerve> You're suggesting a major hf to Monero to do sidechains without MPC. MPC collusion allows the MPs to run off with the funds
11:02:59 <moneromooo> OK, I have no idea what you're on about, I'll shut up :D
11:03:12 <merope> Would it be possible to implement some kind of "payment channel", but for the entire network? That way, everyone sends transactions back and forth inside the channel, and then they all get settled in one big swoop periodically (eg daily/weekly/monthly). If there are N transactions in the channel, then they will occupy *at most* the space of N transactions on the main chain - but as soon as there is more than one transaction between the same two
11:03:12 <merope> parties, you start saving all the space of the N-1 transactions they've done.
11:03:12 <merope> Note that this is different between manually setting up a 1-to-1 payment channel, because it would automatically include everyone on the network
11:06:44 <kayabaNerve> moneromooo: There are three ways to have a peg. Centralization, MPC, and proper sharding. The first two allow the people involved to steal the funds. The first two are the only ones possible without massive HFs to XMR.
11:07:21 <kayabaNerve> Generally, in order to ensure people don't steal X XMR, you have them lock up Y XMR where Y > X. If they steal X, Y is used to pay back the people, and the evil doers lose more than they'd gain.
11:07:43 <monerobull[m]> Did I do a good job "moderating" the meeting yesterday? If you want to, i can do it more regularly :)
11:07:44 <kayabaNerve> This has issues re: XMR, as then you need someone to hold onto Y, which re-asks the question of who should hold X.
11:07:56 <moneromooo> monerobull[m]: yes, you did, thank you :)
11:08:12 <jberman[m]> monerobull: second that^
11:08:46 <moneromooo> Again, I don't know enough about these things to answer usefully I think :/
11:08:48 <kayabaNerve> I'd be much more interested in a payment channel network at this time, tbh.
11:09:10 <kayabaNerve> Yeah, just trying to fill in a couple of the blanks :p
11:09:29 <moneromooo> But you say "who should hold X", and I can answer that: the owner of X. You don't *give* money. You just transfer it, both sides are *your* keys.
11:09:32 <jberman[m]> MPC idea seems like something like this? https://eprint.iacr.org/2015/064.pdf
11:09:40 <kayabaNerve> I'm the asshole who does know a bit about them and has pings setup for "atomic swaps"
11:09:52 <kayabaNerve> Prime position to try to explain some of the issues with them
11:10:26 <kayabaNerve> As one note, when I refer to MPC, I'm basically referring to X stakers for Y people. With payment channels, it's 2 parties to provide services to those 2 people.
11:10:54 <moneromooo> Well, consensus doesn't actually know both sides are your keys, but usually people will give to themselves.
11:11:37 <kayabaNerve> Though XMR proposals either use VDFs, which aren't feasible from a UX perspective, or a third party who at best is a DoS vector IIRC
11:12:59 <moneromooo> I think my solution is a lot simpler than that, though it has the drawback it does require consensus changes (which wasn't a problem for me).
11:14:34 <kayabaNerve> Consensus changes for payment channels should be a lot smaller than sidechains, and it's important to note PoW doesn't work for sidechains as they can't mint coins.
11:14:50 <kayabaNerve> They can do fees only, ofc, but the point was low fees
11:15:10 <jberman[m]> How do you do it keeping amounts private?
11:15:25 <kayabaNerve> Bridged amounts would be public, or at least selectively revealed. I vote the former
11:15:45 <kayabaNerve> Tbc, I know I wasn't asked :p Just commenting on the general theory in play
11:16:01 <kayabaNerve> ... I'm definitely not the person to ask about if there could be a private version
11:17:45 <moneromooo> In my version they're public, but I assume they could be made private using the same system monero uses to prove sum(in) - sum(out) == 0
11:20:18 <jberman[m]> can you walk through how it works?
11:20:37 <mj-xmr[m]> > <@anarkiocrypto:halogen.city> Losing a physical wallet is your fault. Someone deleting a blockchain that contains your money is not your fault.
11:20:37 <mj-xmr[m]> > 
11:20:37 <mj-xmr[m]> > At least store the old blockchains somewhere, even if they aren't used by nodes anymore. Then people could maybe recover their funds for a fee.
11:20:37 <mj-xmr[m]> Agreed.
11:20:46 <mj-xmr[m]> (with the 2nd part)
11:21:34 <DataHoarder> allow only "removing" from there, no longer transacting
11:21:50 <DataHoarder> this has the feeling of "privacy optional" except it's a sidechain
11:22:38 <moneromooo> Well, I don't know how it'd actually work in detail in a monero version.
11:23:03 <moneromooo> I mean with private amounts and all.
11:23:30 <moneromooo> Details would be left as an exercise for crypto-clued people :)
11:25:00 <kayabaNerve> I'm most worried about how the sidechain would come to consensus, hence my advocacy for payment channels.
11:26:12 <moneromooo> Well, it could a single consensus.
11:27:07 <moneromooo> The one data point I have is what I have done for TF, where it's one consensus, the monero style TXO based system, and an account based system, with atomic swaps between both.
11:27:33 <moneromooo> That's a single set of consensus rules, based on monero. One person can transfer between both at will, no third party.
11:28:12 <moneromooo> Now, none of those two end up dumped after a year, but that's my example of such a swap system being possible without the complications above.
11:28:15 <kayabaNerve> It can't be one consensus without all data being shared. Townforge is a single chain. Here you're proposing multiple
11:29:19 <moneromooo> Well, technically it's one chain, but several... sub things ? that don't interact with each other except by transfer between the two.
11:29:46 <kayabaNerve> The second chain could provide XMR miners with all the info and they can mine a hash of the next block onto XMR itself, providing the next block for the sidechain?
11:30:04 <moneromooo> So making the secondary one have a timeout, and spawning another every N months, you get that kind of overlapping chains you can hop.
11:30:20 <jberman[m]> the Monero TXO gets locked I assume and is redeemable by its equivalent amount? so when you unlock it, it's known that it's that specific TXO getting unlocked by an observer
11:30:32 <kayabaNerve> XMR is advanced by PoW. The economy isn't there for sidechains to have PoW. Fees will be minimal, can't mint coins, and if the difficulty is too low, proofs will be forged emptying the chain.
11:31:59 <jberman[m]> idk, I love the idea. I want to hear more/understand if/how it can be done privately
11:32:04 <kayabaNerve> You could PoS. You have no place for people to lock their stake.
11:32:16 <kayabaNerve> That's my objection here.
11:32:38 <kayabaNerve> The giving miners data for them to craft blocks whose PoW is XMR's alone should work out?
11:32:46 <kayabaNerve> You just need miners to adopt sidechains in question
11:33:04 <moneromooo> I rather nebulously think the answer is that they aren't totally separate chains that'd have their own PoW, but the idea is too vague in my head to argue.
11:34:21 <moneromooo> They'd have to be separate enough they can be removed when timing out though. Maybe merge mining with an extra incentive in the monero block reward (main chain).
11:34:38 <moneromooo> (or, rather, penalty if you don't merge mine)
11:35:27 <kayabaNerve> Can you convince the majority of miners to include a notarization in exchange for sidechain fees/unclaimed funds?
11:35:57 <moneromooo> No idea. I wouldn't do that.
11:36:57 <jberman[m]> I don't see why a miner wouldn't include tx's that earn them >0 fee if it's all on the same chain, even if it's just 0.0000000000001
11:37:02 <kayabaNerve> And then a 51% attack could still steal funds under this system where miners include a notarization. They can claim the sidechain did anything they want and...
11:38:17 <jberman[m]> It's all the same chain broadcast to all nodes on the network if I'm understanding right
11:38:48 <jberman[m]> just 2 puddles sorta, the fast puddle, and main chain
11:39:13 <moneromooo> Yes, though in a way that one puddle can be dropped.
11:39:48 <jberman[m]> well not fast, sorry. the low fee puddle
11:39:52 <jberman[m]> same block interval
11:42:21 <jberman[m]> <jberman[m]> "the Monero TXO gets locked I..." <- is this how it works in TF?
11:43:04 <moneromooo> No, it's destroyed. And an equal amount created on the game side.
11:43:27 <moneromooo> Same way for withdraws, TXO created, game balance reduced, atomically.
11:43:40 <moneromooo> I do not see why it would not work with TXO systems on either side.
11:44:35 <jberman[m]> I see I see
11:45:16 <jberman[m]> I think that's a pretty neat idea
11:55:27 <jberman[m]> How could the main chain keep enough state to know that the peg-ins are definitely correct? Isn't it necessary to maintain the state all the way back from coinbase -> next output -> next output, etc? maybe this is what kayabaNerve was getting at
11:55:41 <kayabaNerve> Yep
11:56:30 <kayabaNerve> You can solely publish the relevant data. You need to still verify it. You can't run PoW hash checks and use the 51% rule because the value locked exceeds mining rewards.
11:56:38 <kayabaNerve> You can't run PoS because you can't get stakers.
11:56:47 <moneromooo> You mean the transfers to/from ? Yes, you're right.
11:57:09 <kayabaNerve> You can advance the chain using XMR itself, with the majority of miners publishing the next block for the sidechain, yet that doesn't stop lying about transfers from the sidechain to main chain
11:57:49 <moneromooo> Maybe there's a way to prove the set of transfers at the end of a chain, and store that in a monero block. That proof wuld have to be massively smaller then the dying chain. I don't know whether possible though, but it sounds plausible :)
11:58:12 <moneromooo> But good point here, that's a roadblock.
11:58:34 <kayabaNerve> You may be able to use the full list of signatures BUT without the usual TX data structure?
11:58:48 <kayabaNerve> But that wouldn't stop double spends
11:59:21 <kayabaNerve> It effectively requires moving XMR to PoS OR just centralizing it.
11:59:48 <kayabaNerve> OR payment channels. They don't have this debacle
11:59:55 <mj-xmr[m]> The industry cats that I have to work with, should come to monero channels to learn what a brainstorming should look like :)
12:01:26 <mj-xmr[m]> what->how
12:03:11 <moneromooo> Why would it not stop double spends ?
12:04:06 <kayabaNerve> Because there's no proof the provided signatures are from the chain in question
12:04:17 <kayabaNerve> Someone could submit [] and say that's all the TXs. 0 invalid signatures
12:04:26 <kayabaNerve> XMR accepts it. There's no invalid signatures.
12:04:29 <kayabaNerve> All funds are now burnt
12:05:03 <kayabaNerve> OR someone just drops the last few of them
12:05:14 <kayabaNerve> OR someone drops the last few, and appends a new signature, moving the funds to himself
12:05:44 <kayabaNerve> Or herself or themselves, I believe in equal opportunity crypto criminals :p
12:06:17 <kayabaNerve> Not that there's anything necessarily illegal about this
12:06:54 <moneromooo> That proof would be validated by miners at the end chain, and added to the monero chain.
12:07:18 <moneromooo> It cannot be replaced after the fact by an invalid proof (unless you rewrite the monero chain).
12:07:56 <moneromooo> If you add sufficient delay between proof generation and actual subchain death/deletion, you can prove with enough certainty the proof is the right one, no ?
12:07:59 <kayabaNerve> That could work. If you trust the majority of miners to not collude though, and publish the summary, then you don't need the intermediary signatures. Just a final balance sheet
12:09:07 <kayabaNerve> So in each XMR block, miners publish the hash of the next sidechain block in exchange for fees. At the end of the sidechain, miners publish a final balance TX. 
12:09:19 <kayabaNerve> As long as the majority of miners run software enforcing this, it works out
12:10:54 <kayabaNerve> And there isn't a surge at the end to temporarily seize the funds to defraud centralized institutions
12:11:20 <kayabaNerve> ~21 blocks of control for all value in the sidechain spent on an exchange
12:11:45 <kayabaNerve> OR do an extra timelock of anywhere from 100b to a day or two. Nuke that possibility
12:15:05 <moneromooo> Thanks for thinking about this :)
12:15:25 <kayabaNerve> Happy to. Sorry for being an ass earlier
12:16:54 <kayabaNerve> That should be relatively simple to code and so on. In order to force miner's hands, you'd want a single binary despite effectively being two nodes. It also secures the IPC aspect
12:17:55 <moneromooo> You weren't.
12:18:21 <moneromooo> You just assumed I was using words to mean what they actually mean, and I was much woolier :D
12:20:39 <moneromooo> vtnerd: I fixed those conflicts you mentioned. Thanks.
14:17:06 <monerobull[m]> I don't know how complicated it would be but could whoever is responsible add a rss feed for the monero.space forum?
14:27:47 <t-900-a> <monerobull[m]> "I don't know how complicated..." <- ask here: #monero-space:monero.social
14:28:06 <monerobull[m]> Thanks
14:29:59 <t-900-a> <monerobull[m]> "https://www.reddit.com/r/Monero..." <- I have a current use case, I'm not going to use reddit. Should I message it here or put it on github?
14:30:57 <monerobull[m]> You can post it here and also Dm it to me, I'll bring it up next meeting
14:33:40 <easrng> Is there a better place than here to ask about https://github.com/monero-ecosystem/monero-javascript/ ?
15:22:21 <Guest7936> Hello everyone. I want to learn Monero and if I can contribute in the future. I started reading the Official Wallet's source code (which seems to fully define the protocol as well). However the code is huge and complex. What parts should I start first, if I am more interested in knowing the protocol, but not the wallet features?
15:24:37 <moneromooo> Protocol as in P2P traffic ? As in the underlying crypto ?
15:25:19 <Guest7936> what is collectively known as the Monero protocol
15:25:28 <UkoeHB> Zero to Monero 2nd edition
15:25:32 <Guest7936> probably encompasses the crypto and the P2P nodes
15:26:07 <moneromooo> Probably crypto then, and what UkoeHB said is probably better than looking at the code first.
15:27:35 <Guest7936> nice reference!
15:27:37 <Guest7936> thank you!
15:38:20 <t-900-a> <monerobull[m]> "You can post it here and also Dm..." <- A well-established ethereum nft project in the upcoming weeks was planning on doing a giveaway of a 1:1 Monero themed nft. To enter into the giveaway participants opt-in by using the locked_transfer feature to force themselves to HODL an unknown amount for 3 years. After a period of a week or two, a random tx id is chosen as the winner. The winner has to submit a proof of transaction.
15:38:44 <t-900-a> The idea was to bring in "normies" and show a more fun side to Monero.
15:39:23 <t-900-a> Obviously the project would be scraped if the unlock time field is removed.
15:47:22 <monerobull[m]> It's not like the feature would be scrapped by tomorrow, interesting use for sure but how do you prevent someone from just sending hundreds of tiny locked transactions to themselves?
15:50:26 <t-900-a> The only way to do that would be privacy invading (view key), so no, there is no sybil resistance
15:54:52 <t-900-a> <monerobull[m]> "It's not like the feature..." <- If a network upgrade removed the field, then the funds would effectively be unlocked, right? Probably not an issue, this is more of a marketing effort than anything else
15:55:11 <monerobull[m]> No, locked funds stay locked
15:56:14 <easrng> Is there documentation on the transaction metadata format or should I just read the code?
16:01:18 <monerobull[m]> It would ignore any input into the field and set it as 0. Old transactions stay locked.
16:04:28 <t-900-a> <monerobull[m]> "No, locked funds stay locked" <- So the change wouldn't remove the field itself, it would just remove the code that writes to that field?
16:05:03 <UkoeHB> There would be a new format for new tx. Old tx would stay in the ledger.
16:18:34 <easrng> wtf is appservice-irc doing lol
21:34:57 <ArticMine> On fees. Once we reach 300000 bytes per block fees are set by the penalty. The current minimum fee of was set at 20% of the minimum required to scale with a tx size of 3000 bytes, which once we get close to 300000 is too small. One can increase fees without a HF by increasing the reference tx size but this can encourage miners to accept txs directly and bypass the nodes. 
21:36:02 <ArticMine> Increasing the reference tx size means we allow for a higher rate of scaling at minimum fee