For linkable ring signatures, is there a reason key images are k*Hp(K) instead of k*H where H is another basepoint? Just that it means solving the discrete logarithm once wouldn't break all ring sigs? Or is there an inherent flaw in using the same basepoint for all keys in a ring?

sarang suraeNoether ^

I believe using a constant basepoint would be faster since you can precompute it to some degree, and hash to point functions are a pain from what I've seen.

Using a common basepoint can be used to link signatures due to linearity

It's described in the CryptoNote whitepaper on page 18

Some newer constructions use a common basepoint but invert the scalar instead (and account for this in the signature/proving systems)

Thanks!

Interestingly, this same issue arose in the construction of the dual-key DLSAG construction

are bulletproofs verified faster than borromeans?

Extremely

An entire batch of bulletproofs can be verified in a single multiscalar multiplication operation, which scales well

(and it's only a marginal added cost per proof in the batch)

ah nice

There are benchmark tests

I don't have the numbers handy anymore comparing them, but it's substantial

Aha, found some old numbers

To verify a batch of 128 separate 2-output borromean proofs would take 12186 ms (on one test machine). The same operation with bulletproofs would take ms

^ koe

The current numbers _may_ be faster... we applied some further speedups, and I don't remember if the numbers I just gave account for this

Whoops, the earlier line should have said that with bulletproofs would take 420 ms; sorry about that

That's only 3% of the old time

I did not remember that was such a speedup for the common case :o

I should re-run those numbers and confirm those are current

but at any rate, batching yields substantial improvements

damn!

Praise be to Buentz/Bootle et al ^_^ And MRL.

I discovered Monero is down to around 10x bitcoin transaction sizes, one order of magnitude reduction from before bulletproofs

Heh, we didn't invent bulletproofs, they did

Heh, we didn't invent bulletproofs, they did

AFAIK my only contribution was reporting some errors in the algebra (didn't affect the correctness, just the presentation)

You wrote the code from the paper.

that's a feat in itself

And if not for that, you deserve praise anyway :D

hey sarang what happened with your technical note "Application of Bulletproofs in Monero Transactions", I have a copy dated March 5, 2018

The updated bulletproofs paper covered it

is this the updated version? eprint.iacr.org/2017/1066.pdf

the size difference is less than 10x, ignoring difference in functionality

1 in 2 out bitcoin is >200 bytes, 1 in 2 out monero is 1.7 kb

2 in 2 out btc is 250, 2-2 xmr is 2.3kb, so still <10x

actually 2.5kb so right around 10x

If my dream of compressing MLSAG scalars comes true it will be reduced an additional 670 bytes per input

640

That's a LOT for inputs...

Su much that it might even go negative. Typo ?

I have a dream that one day this protocol will scale into the heavens

MLSAGs take up a lot of space, 32bytes*ringsize for just the scalars

Well, I'll not bother you again then, give you all the time you need to cook that up ^_^

32*2*ringsize actually

koe: I do not think your method is possible

But prove me wrong :D

Does anyone think the general donation fund's custodians would be willing to pledge a bounty to anyone who provided a solution? Probably no bounty for proving it has no solution though.

Ill offer 5 XMR. Any recommendations on formalization? Draft 3 justpaste.it/3i70b

I was thinking more about the problem you brought up, koe

Ah rats, koe is away

I think that a solution to the problem would imply that the underlying PRNG is insecure, since you'd effectively be finding a preimage

and that in turn would break the security of the signature construction

(but I haven't formalized or proven this!)

Tiny *and* works even with insecure PRNGs!

int prng() { return 4; }

there ya go

<Isthmus> Is there a writeup for the possible mitigation of the Janus attack? Third schnorr sig right?

There's a much better approach: adding the point `R' = rG` to the transaction, and doing a particular equality check

quite efficiently, too

I'm working on a short writeup of possible consensus updates that includes the mitigation, as well as hidden timelocks and CLSAG signatures

sarang I also have a hard time imagining a solution, but it could be my own ignorance which is why I don't want to give up. Much more precise writeup justpaste.it/3ilv7

<Isthmus> @sarang: +1 to all of that

important point with that mitigation is it doesn't work on view-only wallets

The short Janus mitigation costs 32 bytes per subaddress output and has a single extra equality check only for outputs you detect (so there's no extra full-chain verification required)

true

Hidden timelocks cost 32-64 bytes

and some extra verification

actually it should be 32 bytes per transaction which contains subaddresses, since you only need one transaction private key for all the subaddresses (reuse r for all subaddresses, and generate new r for non-subaddresses, so rG applies to all the subaddresses)

suppose 3 outputs, 2 are subaddresses; include in tx extra: r1G, r1Ks1, r1Ks2, r2G, where r2G is used by the non-subaddress

hey guys, i've been horribly sick for the past few days

i've been in a hole

please accept my apologies for not bringing the community up to speed

sarang, i have notes on CLSAG for you

biggest problem first: for two rings R and R*, a secret key x with public key X in both, for two messages m and m*, the definition of linkability does not imply that Link(Sign(m, R, x), Sign(m*, R*, x)) = 1

unless I'm misreading it

In particular, use R = R* = {X, Y} for any other fixed public key Y

then R \cup R* has 2 elements, 2 signatures have been computed, the definition provided allows Link to output 0

the rest of my notes are copyediting notes, which i'm going to dump into your PMs

hi suraeNoether, you feeling better?

suraeNoether: I don't see a way to set up a challenger-player game to capture precisely the case you mentioned

There isn't a good way to know that the player used the same private key

(from the challenger's perspective, I mean)

The Backes-style (k+1)-signing game does capture this, at least

koe hi not really

sarang: i'll think about it tonight

i braindumped the rest of my notes on you in PM

damn

Oh, I'mma copypasta some stuff over here from -dev for later reference (otherwise I'll lose it in backlog) and because some might find it interesting.

I've been looking a bit into transaction selection algorithms employed by miners

Let’s say the mempool contains apathetic or many transactions, such that including them results in a decrease in the *total* payout. We define two types of miners: altruistic miners mine the transaction(s) and take a hit to their bottom line (i.e. make a donation) so that transactions get processed. A rational miner will only mine subsets of the mempool that don’t decrease the total reward

(We see lots of altruistic blocks, anything below the main trend)

It used to be very common, many blocks in a row would be altruistic:

Now it is rarer, but still happens. Here is some very recent data:

(Altruism is disabled in the current core software, so this indicates that somebody is using customized software to construct their blocks).

Oh, I should calculate their hashrate

1 sec

Eh, it'd be a lower bound anyways, since convoluted with mempool history

are all those blocks actually larger than the penalty free zone? e.g. it's not people accepting less than the block reward for no reason

could probably just check if size > 300kB, no need to go all in

it's 20kB v1, 60kB v2, 300kB v5; where v1 April 18, 2014; v2 March, 2016; v3 September, 2016; v4 January, 2017; v5 April, 2017

just a hair over 300 kB

x-axis = block height

y-axis = emission

color = size

interesting

Looks like a string of almost-full and slightly-too-full blocks in a row

Still don't have an easy way to look for underclaiming, without implementing a bunch of block weight tracking

Differentiation between altruistic mining (where emission + fees + penalty = payout) with underclaiming (emission + fees + penalty != payout)

The reason I can't tell the difference between them yet, is because I haven't implemented the calculation for the penalty

So I can't tell if the sides of the equation balance

are you plotting emission or total payout?

emission

Calculated by `payout - SUM(fees)`

emission always falls when block sizes are high

Yea, the penalty term

might as well plot total payout, then visual outliers below the curve are altruistic

or underclaiming

Sure, I've got that handy too

some people are paying a lot of fees lmao

Ah yea, to be more precise, miners below the curve in *THIS* plot are altruistic

(not the plot that I showed earlier, since that didn't take into account fees)

someone screwed up back around 1300000

otherwise 0 altruistic miner visible

Heh, yeah looks like blocks are constructed rationally these days

there still might be suboptimal blocks (transactions that aren't justified by fees when block weights above penalty free zone)

Here's a closeup of that whoopsie around 1300000

Which almost looks to be independent of block size

But maybe I need to adjust the color scale

well at 1270000 the block size changed color but pattern remained

Sorry, I wish there was a color bar on here.