has this been looked at? arxiv.org/abs/1912.07497

"We present Blockchain DoS (BDoS), the first incentive-based DoS attack that targets PoW cryptocurrencies. Unlike classical DoS, BDoS targets the system's mechanism design: It exploits the reward mechanism to discourage miner participation. Previous DoS attacks against PoW blockchains require an adversary's mining power to match that of all other miners. In contrast, BDoS can cause a blockchain

to grind to a halt with significantly fewer resources, e.g., 21% as of March 2020 in Bitcoin, according to our empirical study"

Monero is immune to this :D

At least this is what I understood from the paper. In Monero you have to send at least a fluffy block so other nodes can fully verify it

Plus Monero miners don't stop mining, ever. I'm not aware of any pool software that does it. They all keep mining on some blockchain tip no matter what.

"So far, we have assumed that no rational miner mines on the

block header." <--- you can't mine just on the block header in Monero since you need actual transactions to verify mempool transactions. Transactions reference each other by indices in Monero.

so if we change that reference (which has been discussed) - we could open up for this kind of vulnerability? maybe?

moneromooo can you confirm that it's impossible to mine without having the latest block in full?

You need the block template.

The block template is basically the block, except the set of txids in it is replaced by the number of txes and the merkle tree of the tx ids.

So is this attack viable? Some miner announcing only block header to create disarray between other miners?

Block template is created from mempool transactions and it also references previous block hash, right? Mempool transactions don't reference previous block because of 10 blocks spend limit, so the attack might be viable?

You mean a miner sending a block which includes a bad tx on purpose ?

No, read the paper arxiv.org/abs/1912.07497

Maybe later.

Attacker sends only block header. Maybe this is specific only to Bitcoin and forks because it says Ethereum is not affected.

it's a game theory based attack, it assumes that miners will stop mining because they'll wait for the full block

isnt that patchable? ignore if you dont get the full block and continue mining your existing tip?

Sounds familiar to the monero attack in a way.

Inge- Greedy miners are incentivized to not ignore it. Game theory. I want to know if Monero protocol actually allows it.

Current monerod will probably do just that - ignore it and keep mining

but if it's not a part of consensus, greedy miners can in theory exploit it

What is the current status of DL-based zero knowledge proofs?

I figured I'd ask here since Monero is one of the few cryptocurrencies using Bulletproofs in production

In my usual circles, ZKPs like PLONK and Groth16 are the go-to and systems like Bulletproofs are somewhat forgotten

<mikerah[m] "What is the current status of DL"> Isn’t Halo a DL based zkp based on PLONK?

Yes

I think that is the current state of the art for DL based proving system; I usually do not think of PLONK and DL based proof systems as being separate though

PLONK uses pairings though from what I understand

Oh right, vanilla plonk does

And turbo plonk

But the pairings i believe is only because it is using the KZG commitment scheme

If you swap out the commitment scheme like RedShift did, then the pairings would disappear. Or if y out swap out the commitment scheme with a DL based commitment scheme then you get something close to Halo

I think Redshift swapped KZG10 for a FRI based commitment scheme

The redshift paper can be seen here: eprint.iacr.org/2019/1400.pdf

But you are right in that we usually think of PLONK as being the version with KZG

Yep

I'm surprised that the team that came up with RedShift isn't really using it

I think it comes with a few problems

Since FRI is not homomorphic, you can’t use the linearisation trick to reduce the proof size

And the speed AFAIK will not be better than using pairings by a long shot

So the only advantage is transparency form what I can see

But in practice, there a probably a few things that one can do to reduce the proof sizes of schemes that use FRI since starkware seems to be able to get practical efficiency

* So the only advantage is transparency from what I can see

Yeah I think so, maybe when combined with rollups, you can do some sort of batching

The proof size also grows the more custom gates you add into the system for non-homomorphic commitment schemes like PLONK, so it seems like an uphill struggle, since more custom gates usual lot equals more succinct circuits

* The proof size also grows the more custom gates you add into the system for non-homomorphic commitment schemes like FRI, so it seems like an uphill struggle, since more custom gates usual lot equals more succinct circuits

Halo2 uses PLONK so I think that's where you come a little bit confused

The original Halo scheme didn't make use of PLONK

Yeah you’re right, I erroneously call Halo and Halo2 the same thing

I don’t think anyone talks about the old Halo anymore, so I just use that name for the one with PLONK

I think the old version used Sonic?

<kenshamir[m] "I think the old version used Son"> Yep , pg11, Section 5(Main Argument) eprint.iacr.org/2019/1021.pdf

> <@kennonero:matrix.org> I think the old version used Sonic?

* Yep. pg11, Section 5(Main Argument) eprint.iacr.org/2019/1021.pdf

so would this be greater efficiency (size or time) or better robustness than bulletproofs?

<gingeropolous "so would this be greater efficie"> Hmm I think that for bulletproofs rangeproof it would be hard to beat with a transparent setup. Although it would be interesting to see the comparison with Halo, since efficient rangeproofs are done a bit differently in PLONK based systems

For general proofs, I think Halo would be the better DL based system, due to the fact that it can use custom gates

Halo2 not Halo *

I think the key difference between Halo/Halo2 and Bulletproofs is the support for recursion

Halo et al supports recursion out of the box whereas for Bulletproofs one would need more work

recursion in bulletproofs is not too hard but has no real benefit

you get compression but validation takes even longer

I was under the impression that recursion in Bulletproofs can be achieved the same way as it is in Halo

This is the paper which generalises the scheme Halo uses: eprint.iacr.org/2020/499.pdf

oh this is very interesting

I think you can also swap out the inner product argument that bulletproofs uses for any PC_DL, as long as it satisfies certain properties

yeah, ok, i think you could extend this to bulletproofs

yeah my first tendency when doing anything cool with BPs is to throw away the inner product proof

although even verifying a "bare" bulletproof involves doing a giant EC multiexponentiation

but one that's easier to describe and probably easier to put into one of these accumulator proof thingys

Haha yeah it's quite exciting that you can separate the commitment scheme from the IOP layer

<andytoshi "but one that's easier to describ"> I think this is what Halo did, but I have not read the updates, so they might have diverged from BPs inner product by a lot

yeah, it's super convenient. i suspect BPs are the only compact zkp out there that will be reasonably implementable on secure hardware, for some time

because of that

kenshamir[m]: i've been really out of the loop on all these developments :(

zkboo etc i'm sure you can do in secure hardware, and much faster than BPs even, but the resulting proofs are pretty big

<andytoshi "kenshamir: i've been really out "> Leave for a month and so many things happen :)

hah right, i'm scrolling through all these 2020 citations

and i'm like, i was busy this entire year, how did all y'all find time for this

amazing how much manpower there is on this now

<andytoshi "hah right, i'm scrolling through"> I think there is a shift towards efficient provers from the ones in 2020 that I've read

Concrete efficiency

This just came out a hour ago

You can replace the polynomial commitment scheme in Halo with anything even a FRI

<mikerah[m] "You can replace the polynomial c"> Yep, I think of Halo2 and PLONK as using the same IOP layer, with just different commitment schemes. The PCD paper, also notes that you can do recursion with KZG10 instead of a DL based scheme

<mikerah[m] "eprint.iacr.org/2020/153"> This is exciting, I wonder what the advantages are to using this vs Halo2

The advantages are problem more with respect to a particular usecase

For example, in Monero, using Halo Infinite might make more sense due to the primitives used in Monero instead of Halo 2 which requires primitives that Monero doesn't use

Oh, they generalize the results to even FRI

I believe the interesting result from this paper, is that the PCS does not need to be efficient

<mikerah[m] "For example, in Monero, using Ha"> yeah Halo Infinite seems to be a more general construction, from reading the abstract

Preprint on ring selection by some of the Omniring authors: eprint.iacr.org/2020/1550

8

don't mind me.