Sorry, catching up on the last few days

Since lowering the lock time is a perennial discussion, I wrote up a quick note the last time it came up

Maybe I should move this to an MRL repo since it's a biannual discussion

Also RE sarang resarch updates, good point.

I went ahead and added a `PRELIMINARY RESEARCH DRAFT` watermark to the CCS figure

hey, it's been a while but I wondered what you thought about revokable branched outputs

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.

Remind me the construction of these outputs?

I recall them being discussed a while back but it's been a while :/

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

Well, functionally CLSAG and MLSAG should be equally useable for anything that requires parallel signing across multiple keys (e.g. signing and commitment keys)

You still store the auxiliary linking tags, but just don't test them for uniqueness after you do the algebra

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?

Do you mean on chain as part of the transaction structure?

All linking tags (the "real" linking tag and any auxiliary linking tags) must be stored with the transaction, to enable verification

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

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.

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?

needmoney90: I don't follow... who is proving what to whom about what quantities exactly? And what data do the players have?

philogy: correct

This would be an orphan proof on-chain, so all parties have access to chain data.

And one party has access to an orphan block somewhere in the past

philogy: you replace an extra set of scalars (the size of the ring) by an additional auxiliary linking tag per parallel key

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.

Just the compact proof

Hmm, I don't know if that is possible given the PoW structure

if I'm understanding correctly

Would it be possible to rearrange the structure in a future fork so that it is possible?

Hypothetically.

The fact that you don't have the entire block, but want to prove something about hash inputs related to it, feels fishy

I mean for Bitcoin I would just use the header

You hash the block, and include blockhash in the header

Which means you wouldn't have to include the whole block to prove the orphan

Just the header

Are you effectively asking for a proof of knowledge of a hash preimage?

Hm.

If so, with the current system you'd need some kind of insane arithmetic/boolean circuit

In my hypothetical proposal, my goal is for miners to be able to prove orphans occurred to increase the block times.

and for randomx that feels... basically impossible

Ah I see

What does the network know about the orphan blocks?

Nothing, right?

Miners encounter them

Everyone does

Right, but a verifying node on the network doesn't see them

Since by definition they aren't part of the chain

So if my node comes online and requests the chain, it isn't receiving orphan data

This proposal wants the network to be able to adjust its own block times to handle increased load

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

I guess you could "prove" that a block is an orphan by simply showing that's not part of the longest chain

As our block sizes rise, orphan rates will rise too.

The only way to increase network throughoute at that point is increasing block times, either manually or through some self-regulating scheme like this

Throughput*

needmoney90: Monero also has block headers

Will they work for this purpose?

The mining/block template is probably my weakest area

Eh. That's probably some of the crypto actually.

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

I want the network to be able to scale block times when provided proof an orphan occurred.

And if that requires including the entire orphan block in the chain, it's unworkable

The network adjusts the difficulty automatically already based on block times

This would be another multiplier on diff.

And reward

Simultaneously

are

are you proposing a scaling solution of some sort I don't fully understand what you're proposing

Yes

This is a scaling solution.

So how should the network react if it detects orphan blocks?

Block times should rise slightly until the orphans drop (or we hit a cap)

if the difficulty is too low the block times will be below the target anyway. Adding this metric for difficulty adjustment requires the assumption

that the current mechanism doesn't adjust well enough but it does, doesn't it?

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.

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.

Not harsh at all

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

It's not just a deadweight loss in network hashpower

High orphan rates actually seem to stall scaling

Interesting, seems like a minor issue though in comparison to other scaling problems.

sarang: anyway what did or do you think about revokable branched outputs?

philogy: I'm trying to hunt down some of the original discussion and notes on this

I fear that I've let the details slip my mind over time :/

Do we have a figure like this for Monero?

^ Is for Bitcoin

I find that visualization style super helpful for thinking about stuff like this

Our PoW still boils down to hashing the block header, Merkle root, and txn number (+1) right?

Yes AFAIK.

Oh wait needmoney is missing.

test

I have returned

what did I miss

Ok, so reporting an orphan takes {block header, Merkel root, txn number, nonce}

And the verification time would be usual block verification time

less, right?

You dont need to validate txes

Ah yea, correct.

does that include parent hash?

This is where things get weird because "orphan" and "stale" blocks are used differently in Monero. I'll just call them alternative blocks.

There are two conditions that we'd probably want to impose:

1) alt block header must reference a previous hash that is already known (does not matter if main chain or previously reported alt)

2) alt blocks should be reported within some window

The first prevents pre-mining, the second prevents hoarding

I want to specifically avoid people precomputing blocks

yeah

I was thinking the same thing

I think only orphans off a parent from main chain makes sense

and also X-block window obv

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)

I still secretly think that we should just have two encrypted voting fields to let miners vote on block size and block time. :- P

It could even just be two encrypted bits, upvote & downvote

I think it could be done with some Paillier cryptosystem

s/bits,/bits, one to upvote\downvote size, and one to upvote\downvote time

Wow I butchered that

Ugh no, that takes 4 bits

Isthmus: now do a chart for wallet2 :D

Voting is gameable

I think that would likely introduce perverse incentives

At least if you use orphan rate as the signal, you can't game it without doing work explicitly not on tip

That feels like such a barrier that gaming is unlikely

sarang: going off for now,

sarang: but if you find your notes I'd love it if you could add them to the issue on github.

Can you link the issue here as well?

Initial BP+ code, with aggregation: github.com/SarangNoether/skunkworks/tree/pybullet-plus

Tomorrow I'll add the fast verifier, and then get batching

Translating from the Python to our C++ framework should be quite reasonable

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

Scalar operations are cheap

Hmm this is an interesting thought experiment. Our economic security model has some quirks, if you think about it.

Normally, users (txn volum) set block size. If users set it too high, protocol intervenes. If protocol drifts too high, miners intervene.

(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)

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.

So I perceive the block size chain of command to be [Users] < [Protocol] < [Miners]

(with the obvious caveat that miners can only veto the protocol limit when mining smaller blocks, and cannot arbitrarily exceed the protocol limit)

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!

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:

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.

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.

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.

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.

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.

Also, I’ve only thought this halfway through, lots of edge cases and whatnot. Again, not proposing that we do this now.

^^ oops, spam for @needmoney90