hello, good day

i see a recursion in that code. Does the bulletproof that Monero uses also have a recursion?

and i don't even know how to run that code, 100^G dependencies ...

<slave_blocker> " i see a recursion in that code...." <- Well, there is a while loop that will perform inner products until it is over. But I dont believe that there is function calling itself until a condition is reached.

right !

that is a blessing :)

<slave_blocker> "and i don't even know how to run..." <- From my experience up to now, it is not trivial to run any Python code that simulates what Monero is doing. Im putting a lot of efforts to do that actually.

i don't like recursive functions

i wish you all the best !

i want to make it verbatim what the bulletproofs are doing.

and as the pedersen commits are additively homomorphic, i want to use Z_p instead of ec points

If everything goes well by the end of next month I will publish some explanations and codes to do that ;)

and use a small p such that the reader can convince himself of that too

i am glad to help :)

again, there is a sort of halving of a vector happening in the range proof of the current Monero code? Does this explain it :

?

furthermore wich cpp file contains the rangeproof in the source of xmr?

<slave_blocker> "furthermore wich cpp file..." <- For BP you can find here: github.com/monero-project/monero/bl…ter/src/ringct/bulletproofs.cc#L724

what is that :

by the time i try to calculate t_1 and t_2 i hit a bump.

Is there a cryptographic reason outputs are limited to 16 when we can have hundreds of inputs? Outputs add 32 bytes in proofs. Inputs add ~half a KB and several more ops.

No.

(it's arbitrary really)

I'm not sure whether the limit was added before the concept of weight was introduced. I believe the limit is intended to prevent someone from stuffing a tx with huge number of outs, which could be used to cheaply

spam the chain (which is less of an issue now with the weight concept) and increase verification time. This can be done with lots of txes anyway, so the difference would be fees.

right, each output needs to be scanned by every syncing wallet

I was about to comment on how this makes no sense regarding nodes, yet when you include wallets in consideration... it makes a bit more sense

We have newfound leeway with view tags? Yet as I noted, each output adds a trivial amount (probably ~140 bytes in total). With a TX size limit of 150kb, we could have 1000 outputs per TX...

Though that is scanned fully as just 4 outputs now, with solely partial processing on the rest. So it may not be an issue overall? Or it may make sense to limit to 64/256 outs?

kayabaNerve, a tx with 64 outs?

slave_blocker: What about it?

Are you asking if one exists or asking why I would want one?

seems only exchanges would need to do that

... right

:p

BP clawback was added after multi output BPs (from commit dates).

The 10-block lock means there's 20 minutes for a given group of funds. The simplest fund management algorithm greedily consolidates without optimization, meaning you can only action every 20 minutes. 16 outputs means you get <1 payment per minute which isn't feasible.

So you can either write a very complicated scheduling protocol which divvies into 10x, re-balances, is able to merge groups temporarily... or write a log scheduler for outputs which is my plan.

Doesn't stop me from advocating increasing the output limit when it's currently cryptographically incredibly cheap and also decently minimal on TX KB which is paid for by fees.

If someone is still in contact with sarang, they could ask whether the limit was made before weight was considered.

I'll ask later today

Send greetings along with it then please :)

Will do :)

BTW p2pool has transactions with hundreds of outputs already today and nothing broke

kayabaNerve fund management algorithm can grow the number of outputs 15 times every 10 blocks (1in/16out transactions). If wallet maintenance takes 1 hour, exchange can have 3375 times more outputs in that time.

Actually 16 times every 10 blocks, so multiplier will be 4096x/hour

sech1: Right. "log scheduler". In this case, log16 :)

Thanks for giving me the heads up. If I wasn't already there, I'd definitely need it

But such scheduler will be eventually limited by the block size

So around 100-150 transactions per block

Or 1600 new outputs every 2 minutes

But that's over 100 user withdrawals per second sustained throughput, and blocks will grow under such load

*10 withdrawals per second

Well, I'm only planning doing 1 line of the pyramid every 20 minutes, for n pyramids. It's not per block. I'm also expecting a small fraction of that load :p This isn't CryptoKitties.

And I'm not tying my code to exact block timing. Just an understanding it needs to assume a delay of at least 20 minutes before the next option to act.

why is there a lock time of 10 blocks ?

why 10 and not 5 ?

does the wallet-cli have a command that disperses the funds into 5 sub-addresses "equally" ?

transfer

ie, transfer A a B a C a D a E a. Up to 15/16 address/amount pairs.

so if i want to buy 5 coffees within 15 minutes i can with the same wallet... Not that i entitle myself at the greatness of arguing in an influencing way about this, and is the issue of lock time not negligible?

<slave_blocker> "why is there a lock time of 10..." <- Output keys are included in rings. We reference ring members by global output indexes. So instead of TX hash X, output O, it's global output O. It's only assigned a global output O once in a block. So that means 1 block. Any reorg with slightly different TXs, even just by ordering, would change your global output index and invalidate your TX.

Setting a lock of 10 blocks ensures reorgs don't change TX validity, so long as the reorg doesn't exceed 10 blocks. There was also a recent discussion on reducing it.

slave_blocker: You'd have to do them all at once, using `transfer coffee1 $1 coffee2 $1 ...` OR have 5 inputs in your wallet, each having sufficient funds for each coffee.

a monerian should have some weight on his shoulders aswell not putting all on the devs

when i say shoulders i meant addresses

... except I think wallet2 will use 2 inputs if possible, regardless of necessity, for privacy reasons. You'd actually need 9 inputs. I'm also not sure if it'll select a low value second input or a random one. In the latter case, > 5 need to have sufficient funds in order to guarantee success

Random IIRC. You can avoid this by twiddling... a couple vars in the wallet.

min-outputs-{value,count}

Set this to 0,0 and it should never pick a second out if not necessary. I think.

"would you like this wallet for buying coffees?

"yes!"

great do step 1

moneromooo, when i was using my wallet-cli i noticed that while inputing the seed there is no auto-completion with tab under linux. Is that good to have?

Since the MRL meeting where we discussed reducing the 10 block lock I have been thinking that wallet-level solutions such as Monerujo's PocketChange may present a privacy risk in some cases of user behavior. If a user spends a large proportion of their wallet's balance, then outputs that are from the same transaction or are temporally closely-spaced will be referenced in that large-value transaction.

Basically, the same risk from a sweep_all operation that has been discussed before.

Probably not. Only the prefix (usually 3 or 4 letters IIRC) matters anyway.

I've been wondering for a while if doing a sweep_single on each output would increase the level of privacy of future spends

Because sweeping a single output actually increases the number of "backwards branches", and thus potential ancestors

Dummy inputs would help in that regard too

Actually, the discussion on "isolated enotes" for collaborative funding makes me wonder if they could be used in a non-interactive protocol that acts kinda like a coinjoin, but with hidden amounts

So that all user transactions in a block could be blended into one big combined tx

That would really blow up the number of potential combinations of associated inputs and outputs - good luck trying to probabilistically match those

moneromooo: Size is as I described (n). Number of proofs is a power of 2 though and they must be padded. Computational complexity follows this power of two and batches have the complexity of the largest included member.

That's why my argument doesn't hold

I'm a bit confused here. BP size of O(log(N)). Verification time is O(N) (N being the number of outputs).

... is BP log(n) in size for amount of proofs? I thought it was n. Regardless, I was more thinking of TX size which would be n per output. The issue is the number of included proofs must be a power of 2 though. So we have 2^4 for 16. If we raise that to 32, it's 2^5, except now every single BP is verified as if it's 32 outputs, so long as any individual BP is included with 17 outputs.

So considering no one legitimately needs that many outputs in a single TX, and it nukes batch performance... there's no reason to raise it

... though I am a bit curious how p2pool handles it given a lack of TX chaining.

I think if you include N dummy proofs, you still pay for them due to the concept of weight.

But it is true I'm not sure the weight includes *dummy* ones actually...

They wouldn't be serialized.

Is that relevant ?

... since TX fee is byte based?

uint64_t bp_clawback = get_transaction_weight_clawback(tx, n_padded_outputs);

So it seems to include the dummy ones in the weight.

Oh

(first approximation)

So if we have a block solely with 2 output TXs, from my current understanding, we'll batch verify with 2^1. If a single TX includes 3 outputs, we batch verify all as 2^2.

That's the issue described by sarang

"how p2pool handles it given a lack of TX chaining." uhmm what?

This is correct AFAIK. But the person will pay for the notional equivalent of 4 non-log outs.

sech1: What

Oh, I see, I think.

moneromooo: But they change every single TX in the block to be batch verified with it

... they affect the batch verification of all TXs in the block?

Better phrasing

When batching, it is faster to verify 8x 2outs than 1x 16 outs. Is that your point ?

kayabaNerve you wrote it, I don't understand what you meant. p2pool transactions are "special", they have 0 inputs and therefore no bulletproofs

moneromooo: 8x 2outs become 8x 16 outs if any single one of them becomes 1x 16 outs

Yes, but that's immaterual to the point AIUI.

... I mean, it's nuking batch verification performance based on a single TX

Oh, for the purposes of my question, I assumed the limit ix 2, not 16. So a 16 out tx has to be split into 8x 2 out txes.

I'll rephrase then:

Okay. I am going to do my best to sum this up.

When batching, it is faster to verify 8x 16outs than 1x 128 outs. Is that your point ?

If we have a limit of 16, and we get 2 TXs of 2 outputs, we batch 2 TXs with 2 padded outputs. If we add a third TX with 9 outputs, we batch three TXs with 16 padded outputs.

Every single BP in the batch has the same padded output count.

Your cited weight code has the individual TX's weight increased for the padded outputs it uses. If it uses 17 outputs, when everything else in the block uses 2, we only charge it +15. In reality, it's +15 +30n

That's my understanding.

sech1: Nothing to do with BPs.

We were discussing log scheduling outputs earlier. The simplest p2pool theoretical implementation directly pays out from the block reward as expected. Given XMR's 16 output limit, that means the miner TX has 16 outputs, and then after 60 blocks, it'd immediately do 16 outputs on each of its outputs until...

OK. So you're saying that the "few out" txes get extra verification time for dummy BPs they never included. Right ?

(when batching)

right

OK. That makes sense then. Thanks.

So in an honest network, we'll frequently batch verify as if each BP has 2 outs. In an attacked network, we'll batch verify every BP as if it has 16 outs. If we increase the limit, which no one needs, the attack also increases.

sech1: I just have no idea how you schedule payments if you're using a log scheduler given the lack of chaining, unless you have some multisig construction in play, which I'm not assuming.

Miner payouts are not limited to 16 outputs

It could be a top 16 gets paid out in that block, and you're not using a log scheduler, or...

Oh.

Do you know whether it'd be faster to verify 15x 2 outs tx plus 1x 16 out tx in two separate, sequential verifications, rather than all these txes at once ?

... never mind then :p

(because we can then make several batches, per number of padded outs)

moneromooo: Literally? No idea. From an estimation standpoint? ... it's pretty expensive.

multiexps are insane. I think my work got 100x with it on a scale of ~40. BPs is hundreds.

So yeah, if we're discussing several bs +30 output counts, it may work out. I wouldn't hesistate to guess though and I think you could write some timing code faster than I could for this :p

True...

moneromooo: I think I tested that and splitting them doesn't help you

OK

moneromooo: I found my old math. I was 10x for my entire protocol, which multiexp was the worst part of, with just 50 keys. I also think at the time I had only made one of my two multiexp targets multiexp so it may be a higher ratio when appropriately cordoned.

Though ofc, UkoeHB has the actual numbers.

Speaking of koe, the discussion also came up that BP+ MPC is a pain to implement relies on a weaker security assumption than BP MPC.

Since Seraphis is no longer focusing on collab funding... not really an issue?

But wanted to forward the note

*pain to implement and relies on

for collaborative funding you'd need to send input amounts to the central tx coordinator anyway, so they know when sum to zero is achieved

so the tx coordinator can handle range proofs locally

it would be a huge pain to try and hide that (if it's even possible)

Or move to the on-chain protocol which preserves privacy yet has higher fees/latency

BP MPC is possible. Can't comment on Seraphis MPC :p

UkoeHB: I messed up here. BPs require stronger assumptions and are a pain to implement over MPC because... what isn't. BP+s do leak amounts in a MPC setting. We discussed it in context of dalek and dalek is BP when I thought they were BP+.

let there be an expression of an inner product like : < a_l - z, (a_r + z)*y + 2^n > ... how to deal with the arithmetic ? How does that expand formally ?

i mean i know the summation formula... how does the expression evaluate ?

i mean a(b + c) evaluates to ab + ac, < ( a + b ) c , d > evaluates to ?

don't get me wrong it's written on my mirrors just fancy !

like poetry.

If i don't get it at least it looks fancy

:]

I think you can thank me for that, seeing how it was merged a mere 15 minutes after i expressed my support of the proposal /s

Here is the analysis of the Federal Reserve data on cryptocurrency use that I discussed at the meeting yesterday:

If you don't want to read it on Reddit, give me a few moments to put it on my website.

Ok here it is. Also available as an onion hidden service