00:39:12 <Isthmus> Sorry, catching up on the last few days
00:39:44 <Isthmus> Since lowering the lock time is a perennial discussion, I wrote up a quick note the last time it came up
00:39:45 <Isthmus> https://github.com/noncesense-research-lab/lock_time_framework/blob/master/writeup/lock_time_framework.pdf
00:40:06 <Isthmus> Maybe I should move this to an MRL repo since it's a biannual discussion
00:41:21 <Isthmus> Also RE sarang resarch updates, good point.
00:41:24 <Isthmus>  I went ahead and added a `PRELIMINARY RESEARCH DRAFT` watermark to the CCS figure
00:42:22 * Isthmus hopes this will minimize FUD potential/
15:42:38 <philogy> hey, it's been a while but I wondered what you thought about revokable branched outputs
15:45:17 <philogy> Haven't updated the paper yet but I recently realized that with CLSAG there wouldn't a lot of additional data that would have to stored along with every transaction.
15:52:41 <sarang> Remind me the construction of these outputs?
15:52:50 <sarang> I recall them being discussed a while back but it's been a while :/
15:56:23 <philogy> The construction involves including an additional public revocation key optionally independent from the recipients address as well being able to assign timelocks to individual outputs. With CLSAG the primary key would be the private revocation key instead of the private one time key. The one time key would still be part of the signature but since revocation keys would be unique they would suffice for link
16:23:07 <sarang> Well, functionally CLSAG and MLSAG should be equally useable for anything that requires parallel signing across multiple keys (e.g. signing and commitment keys)
16:24:02 <sarang> You still store the auxiliary linking tags, but just don't test them for uniqueness after you do the algebra
16:29:40 <philogy> yeah MLSAG would work too it's just it requires less space using CLSAG, with MLSAG you'd need an additional set of r values as part of the signature. With CLSAG do you need to store all linking tags for all keys even the private keys to the difference between the pseudo output commitments and the input commitments?
16:38:42 <sarang> Do you mean on chain as part of the transaction structure?
16:39:00 <sarang> All linking tags (the "real" linking tag and any auxiliary linking tags) must be stored with the transaction, to enable verification
16:39:43 <sarang> I suppose a client could discard them after verification if it didn't need/want to provide chain data to other nodes, as it could for things like range proofs
16:42:49 <philogy> ah I understand so now with clsag you don't have to store as many r values on the blockchain but you do have to additionally transmit the linking tags.
16:47:50 <needmoney90> Do we currently have the ability to provide a compact proof of an orphan that includes both it's parent block's hash and evidence the PoW was performed?
16:49:05 <sarang> needmoney90: I don't follow... who is proving what to whom about what quantities exactly? And what data do the players have?
16:49:24 <sarang> philogy: correct
16:49:32 <needmoney90> This would be an orphan proof on-chain, so all parties have access to chain data.
16:49:48 <needmoney90> And one party has access to an orphan block somewhere in the past
16:49:59 <sarang> philogy: you replace an extra set of scalars (the size of the ring) by an additional auxiliary linking tag per parallel key
16:50:21 <needmoney90> Basically. I want to be able to prove that an orphan occurred within X blocks, and had a valid PoW. But without including the entire block.
16:50:46 <needmoney90> Just the compact proof
16:51:16 <sarang> Hmm, I don't know if that is possible given the PoW structure
16:51:22 <sarang> if I'm understanding correctly
16:51:35 <needmoney90> Would it be possible to rearrange the structure in a future fork so that it is possible?
16:51:43 <needmoney90> Hypothetically.
16:52:10 <sarang> The fact that you don't have the entire block, but want to prove something about hash inputs related to it, feels fishy
16:52:27 <needmoney90> I mean for Bitcoin I would just use the header
16:52:38 <needmoney90> You hash the block, and include blockhash in the header
16:52:51 <needmoney90> Which means you wouldn't have to include the whole block to prove the orphan
16:52:56 <needmoney90> Just the header
16:53:04 <sarang> Are you effectively asking for a proof of knowledge of a hash preimage?
16:53:10 <needmoney90> Hm.
16:53:31 <sarang> If so, with the current system you'd need some kind of insane arithmetic/boolean circuit
16:53:41 <needmoney90> In my hypothetical proposal, my goal is for miners to be able to prove orphans occurred to increase the block times.
16:53:45 <sarang> and for randomx that feels... basically impossible
16:54:00 <needmoney90> Ah I see
16:54:05 <sarang> What does the network know about the orphan blocks?
16:54:09 <sarang> Nothing, right?
16:54:17 <needmoney90> Miners encounter them
16:54:20 <needmoney90> Everyone does
16:54:37 <sarang> Right, but a verifying node on the network doesn't see them
16:54:43 <sarang> Since by definition they aren't part of the chain
16:55:05 <sarang> So if my node comes online and requests the chain, it isn't receiving orphan data
16:55:09 <needmoney90> This proposal wants the network to be able to adjust its own block times to handle increased load
16:55:36 <needmoney90> If you can include the proof in a block as a miner for a slightly higher rewards (via a higher future block time), they have incentive to add them
16:55:40 <philogy> I guess you could "prove" that a block is an orphan by simply showing that's not part of the longest chain
16:56:19 <needmoney90> As our block sizes rise, orphan rates will rise too.
16:56:48 <needmoney90> The only way to increase network throughoute at that point is increasing block times, either manually or through some self-regulating scheme like this
16:56:58 <needmoney90> Throughput*
16:57:04 <philogy> needmoney90: Monero also has block headers
16:58:12 <needmoney90> Will they work for this purpose?
16:58:26 <needmoney90> The mining/block template is probably my weakest area
16:58:42 <needmoney90> Eh. That's probably some of the crypto actually.
16:58:55 * needmoney90 is a dumb
17:00:23 <philogy> If I understand correctly you want to be able to prove that a block is an orphan right? Meaning it isn't part of the longest chain, so all you have to do is show that it isn't by providing a certain number of consecutive block headers. The verifier can then check the proof of work and see that the block is most likely an orphan
17:01:16 <needmoney90> I want the network to be able to scale block times when provided proof an orphan occurred.
17:01:42 <needmoney90> And if that requires including the entire orphan block in the chain, it's unworkable
17:01:52 <philogy> The network adjusts the difficulty automatically already based on block times
17:02:14 <needmoney90> This would be another multiplier on diff.
17:02:18 <needmoney90> And reward
17:02:21 <needmoney90> Simultaneously
17:03:13 <philogy> are
17:03:30 <philogy> are you proposing a scaling solution of some sort I don't fully understand what you're proposing
17:03:42 <needmoney90> Yes
17:03:50 <needmoney90> This is a scaling solution.
17:04:10 <philogy> So how should the network react if it detects orphan blocks?
17:04:45 <needmoney90> Block times should rise slightly until the orphans drop (or we hit a cap)
17:05:53 <philogy> if the difficulty is too low the block times will be below the target anyway. Adding this metric for difficulty adjustment requires the assumption
17:06:18 <philogy> that the current mechanism doesn't adjust well enough but it does, doesn't it?
17:07:07 <needmoney90> This is certainly premature, but other chains have shown this issue at scale. I think we're headed right for it if we get bigger, and I want to address it early.
17:07:37 <philogy> I don't want to sound harsh but how would this help with scaling you aren't increasing the throughput you are just improving the difficulty adjustment if at all.
17:07:51 <needmoney90> Not harsh at all
17:08:41 <needmoney90> When orphan rates spike, miners on other networks have shown the tendency to freeze block sizes, even when they have the ability at the protocol level to add more txes to their block
17:09:24 <needmoney90> It's not just a deadweight loss in network hashpower
17:09:42 <needmoney90>  High orphan rates actually seem to stall scaling
17:13:29 <philogy> Interesting, seems like a minor issue though in comparison to other scaling problems.
17:17:42 <philogy> sarang: anyway what did or do you think about revokable branched outputs?
18:05:25 <sarang> philogy: I'm trying to hunt down some of the original discussion and notes on this
18:05:39 <sarang> I fear that I've let the details slip my mind over time :/
18:34:22 <Isthmus> Do we have a figure like this for Monero?
18:34:24 <Isthmus> https://usercontent.irccloud-cdn.com/file/jGY099d7/image.png
18:34:28 <Isthmus> ^ Is for Bitcoin
18:35:47 <Isthmus> I find that visualization style super helpful for thinking about stuff like this
19:05:11 <Isthmus> Our PoW still boils down to hashing the block header, Merkle root, and txn number (+1) right?
19:05:54 <moneromooo> Yes AFAIK.
19:08:10 <Isthmus> Oh wait needmoney is missing.
19:08:15 * Isthmus pauses block time convo
19:16:56 <needmoney90> test
19:16:56 <monerobux> Test failed
19:17:12 <needmoney90> I have returned
19:17:46 <needmoney90> what did I miss
19:19:24 <Isthmus> Ok, so reporting an orphan takes {block header, Merkel root, txn number, nonce}
19:19:29 <Isthmus> And the verification time would be usual block verification time
19:21:47 <needmoney90> less, right?
19:21:50 <needmoney90> You dont need to validate txes
19:22:03 <Isthmus> Ah yea, correct.
19:24:52 <needmoney90> does that include parent hash?
19:25:03 <Isthmus> This is where things get weird because "orphan" and "stale" blocks are used differently in Monero. I'll just call them alternative blocks.
19:25:03 <Isthmus> There are two conditions that we'd probably want to impose:
19:25:03 <Isthmus> 1) alt block header must reference a previous hash that is already known (does not matter if main chain or previously reported alt)
19:25:03 <Isthmus> 2) alt blocks should be reported within some window
19:25:13 <Isthmus> The first prevents pre-mining, the second prevents hoarding
19:25:15 <needmoney90> I want to specifically avoid people precomputing blocks
19:25:16 <needmoney90> yeah
19:25:22 <needmoney90> I was thinking the same thing
19:25:37 <needmoney90> I think only orphans off a parent from main chain makes sense
19:25:44 <needmoney90> and also X-block window obv
19:27:32 <Isthmus> Yea, if the goal is to inform block time based on the rate of latency-induced alt blocks, it doesn't make sense to include multi-block alt chains (since those would represent something else... an accidentally or intentionally isolated miner)
19:29:42 <Isthmus> I still secretly think that we should just have two encrypted voting fields to let miners vote on block size and block time. :- P
19:30:21 <Isthmus> It could even just be two encrypted bits, upvote & downvote
19:31:16 <Isthmus> I think it could be done with some Paillier cryptosystem
19:32:04 <Isthmus> s/bits,/bits, one to upvote\downvote size, and one to upvote\downvote time
19:32:04 <monerobux> Isthmus meant to say: It could even just be two encrypted bits, one to upvote\downvote size, and one to upvote\downvote time upvote & downvote
19:32:12 <Isthmus> Wow I butchered that
19:32:39 <Isthmus> Ugh no, that takes 4 bits
19:34:28 <endogenic> Isthmus: now do a chart for wallet2 :D
19:56:35 <needmoney90> Voting is gameable
19:56:44 <needmoney90> I think that would likely introduce perverse incentives
19:57:01 <needmoney90> At least if you use orphan rate as the signal, you can't game it without doing work explicitly not on tip
19:57:17 <needmoney90> That feels like such a barrier that gaming is unlikely
20:13:35 <philogy> sarang: going off for now,
20:14:00 <philogy> sarang: but if you find your notes I'd love it if you could add them to the issue on github.
20:14:29 <sarang> Can you link the issue here as well?
20:24:10 <sarang> Initial BP+ code, with aggregation: https://github.com/SarangNoether/skunkworks/tree/pybullet-plus
20:24:22 <sarang> Tomorrow I'll add the fast verifier, and then get batching
20:24:40 <sarang> Translating from the Python to our C++ framework should be quite reasonable
20:25:23 <sarang> I had hoped that some index simplification could be used for some scalar operations, but it appears not; fortunately, that's just a notation irritation, and not an efficiency problem
20:25:49 <sarang> Scalar operations are cheap
23:00:08 <Isthmus> Hmm this is an interesting thought experiment. Our economic security model has some quirks, if you think about it.
23:00:08 <Isthmus> Normally, users (txn volum) set block size. If users set it too high, protocol intervenes. If protocol drifts too high, miners intervene.
23:00:08 <Isthmus> (e.g. picture a few years in the future, when cryptokitties accepts XMR. Users are generating 4 GB txns per 2 minutes, and protocol limits block size to 3 GB txns per 2 minutes, but the network can only handle 2 GB txns per 2 minutes)
23:00:08 <Isthmus> The usual response is “well, if miners can only handle 2 GB blocks, they’ll self-limit to 2 GB”. In other words, we fallback to miners vetoing the difference between the protocol limit and practical limit.
23:00:08 <Isthmus> So I perceive the block size chain of command to be [Users] < [Protocol] < [Miners]
23:00:09 <Isthmus> (with the obvious caveat that miners can only veto the protocol limit when mining smaller blocks, and cannot arbitrarily exceed the protocol limit)
23:00:09 <Isthmus> So, operating on that last-ditch assumption that the majority of miners will act in the best interest of the network, maybe we *want* to approach it from this angle from the start!
23:00:10 <Isthmus> After all, Nakmoto consensus is very well defined and studied, so we can think through it somewhat formally. Likewise for privacy-preserving voting systems. Considering that framework:
23:00:10 <Isthmus> Each miner casts one [encrypted] vote per block on whether or not to increase the block size. Value of `1` is a vote in favor of increasing block size, and a  value of `0` is a vote against increasing.
23:00:11 <Isthmus> Every 100 blocks a new voting window begins. At the end of the window, the encrypted votes are tallied. If >=51 of 100 miners voted in favor of the increase, it passes. Otherwise, block size does not increase.
23:00:11 <Isthmus> Thus we’ve reduced the matter to Nakamoto consensus, which is both 1) the practical fallback anyways, and 2) the main security requirement and guarantee for Monero anyways.
23:00:12 <Isthmus> So framed this way, if the voting system is “gamed” then it implies a violation of the assumption that 51% of miners are acting in the best interest of Monero.
23:00:12 <Isthmus> Anyways, I’m rambling. You could consider variations like voting on block time as well, or having an option to vote for a decrease as well, etc etc.
23:00:13 <Isthmus> Also, I’ve only thought this halfway through, lots of edge cases and whatnot. Again, not proposing that we do this now.
23:00:25 <Isthmus> ^^ oops, spam for @needmoney90