12:37:21 <Inge-> has this been looked at? https://arxiv.org/abs/1912.07497
12:38:17 <Inge-> "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
12:38:23 <Inge-> to grind to a halt with significantly fewer resources, e.g., 21% as of March 2020 in Bitcoin, according to our empirical study"
12:43:33 <sech1> Monero is immune to this :D
12:46:32 <sech1> 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
12:48:57 <sech1> 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.
12:50:25 <sech1> "So far, we have assumed that no rational miner mines on the
12:50:25 <sech1> 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.
13:13:28 <Inge-> so if we change that reference (which has been discussed) - we could open up for this kind of vulnerability? maybe?
13:16:32 <sech1> moneromooo can you confirm that it's impossible to mine without having the latest block in full?
13:18:02 <moneromooo> You need the block template.
13:18:34 <moneromooo> 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.
13:22:29 <sech1> So is this attack viable? Some miner announcing only block header to create disarray between other miners?
13:23:53 <sech1> 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?
13:23:54 <moneromooo> You mean a miner sending a block which includes a bad tx on purpose ?
13:24:11 <sech1> No, read the paper https://arxiv.org/abs/1912.07497
13:24:30 <moneromooo> Maybe later.
13:24:31 <sech1> Attacker sends only block header. Maybe this is specific only to Bitcoin and forks because it says Ethereum is not affected.
13:25:25 <sech1> it's a game theory based attack, it assumes that miners will stop mining because they'll wait for the full block
13:26:56 <Inge-> isnt that patchable? ignore if you dont get the full block and continue mining your existing tip?
13:27:56 <bobandback> Sounds familiar to the monero attack in a way.
13:28:40 <sech1> Inge- Greedy miners are incentivized to not ignore it. Game theory. I want to know if Monero protocol actually allows it.
13:29:45 <sech1> Current monerod will probably do just that - ignore it and keep mining
13:30:16 <sech1> but if it's not a part of consensus, greedy miners can in theory exploit it
15:05:49 <mikerah[m]> What is the current status of DL-based zero knowledge proofs?
15:06:14 <mikerah[m]> I figured I'd ask here since Monero is one of the few cryptocurrencies using Bulletproofs in production
15:06:52 <mikerah[m]> In my usual circles, ZKPs like PLONK and Groth16 are the go-to and systems like Bulletproofs are somewhat forgotten
15:25:09 <kenshamir[m]> <mikerah[m] "What is the current status of DL"> Isn’t Halo a DL based zkp based on PLONK?
15:25:35 <mikerah[m]> Yes
15:27:15 <kenshamir[m]> 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
15:28:42 <mikerah[m]> PLONK uses pairings though from what I understand
15:28:58 <kenshamir[m]> Oh right, vanilla plonk does
15:29:05 <kenshamir[m]> And turbo plonk
15:29:24 <kenshamir[m]> But the pairings i believe is only because it is using the KZG commitment scheme
15:30:37 <kenshamir[m]> 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
15:30:57 <kenshamir[m]> I think Redshift swapped KZG10 for a FRI based commitment scheme
15:31:43 <kenshamir[m]> The redshift paper can be seen here: https://eprint.iacr.org/2019/1400.pdf
15:32:49 <kenshamir[m]> But you are right in that we usually think of PLONK as being the version with KZG
15:33:13 <mikerah[m]> Yep
15:33:27 <mikerah[m]> I'm surprised that the team that came up with RedShift isn't really using it
15:33:54 <kenshamir[m]> I think it comes with a few problems
15:34:18 <kenshamir[m]> Since FRI is not homomorphic, you can’t use the linearisation trick to reduce the proof size
15:34:47 <kenshamir[m]> And the speed AFAIK will not be better than using pairings by a long shot
15:35:04 <kenshamir[m]> So the only advantage is transparency form what I can see
15:35:12 <mikerah[m]> 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
15:35:12 <kenshamir[m]> * So the only advantage is transparency from what I can see
15:35:54 <kenshamir[m]> Yeah I think so, maybe when combined with rollups, you can do some sort of batching
15:37:25 <kenshamir[m]> 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
15:37:38 <kenshamir[m]> * 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
15:40:29 <mikerah[m]> Halo2 uses PLONK so I think that's where you come a little bit confused
15:40:39 <mikerah[m]> The original Halo scheme didn't make use of PLONK
15:41:19 <kenshamir[m]> Yeah you’re right, I erroneously call Halo and Halo2 the same thing
15:41:50 <kenshamir[m]> I don’t think anyone talks about the old Halo anymore, so I just use that name for the one with PLONK
15:42:00 <kenshamir[m]> I think the old version used Sonic?
15:47:25 <kenshamir[m]> <kenshamir[m] "I think the old version used Son"> Yep , pg11, Section 5(Main Argument) https://eprint.iacr.org/2019/1021.pdf
15:47:36 <kenshamir[m]> > <@kennonero:matrix.org> I think the old version used Sonic?
15:47:36 <kenshamir[m]>  * Yep. pg11, Section 5(Main Argument) https://eprint.iacr.org/2019/1021.pdf
16:57:51 <gingeropolous> so would this be greater efficiency (size or time) or better robustness than bulletproofs?
17:04:45 <kenshamir[m]> <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
17:05:21 <kenshamir[m]> For general proofs, I think Halo would be the better DL based system, due to the fact that it can use custom gates
17:05:42 <kenshamir[m]> Halo2 not Halo *
17:40:45 <mikerah[m]> I think the key difference between Halo/Halo2 and Bulletproofs is the support for recursion
17:41:05 <mikerah[m]> Halo et al supports recursion out of the box whereas for Bulletproofs one would need more work
17:47:50 <andytoshi> recursion in bulletproofs is not too hard but has no real benefit
17:48:07 <andytoshi> you get compression but validation takes even longer
17:56:51 <kenshamir[m]> I was under the impression that recursion in Bulletproofs can be achieved the same way as it is in Halo
17:57:38 <kenshamir[m]> This is the paper which generalises the scheme Halo uses: https://eprint.iacr.org/2020/499.pdf
17:59:03 <andytoshi> oh this is very interesting
18:00:37 <kenshamir[m]> 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
18:00:49 <andytoshi> yeah, ok, i think you could extend this to bulletproofs
18:01:06 <andytoshi> yeah my first tendency when doing anything cool with BPs is to throw away the inner product proof
18:01:20 <andytoshi> although even verifying a "bare" bulletproof involves doing a giant EC multiexponentiation
18:01:58 <andytoshi> but one that's easier to describe and probably easier to put into one of these accumulator proof thingys
18:02:33 <kenshamir[m]> Haha yeah it's quite exciting that you can separate the commitment scheme from the IOP layer
18:03:25 <kenshamir[m]> <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
18:03:28 <andytoshi> 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
18:03:32 <andytoshi> because of that
18:03:44 <andytoshi> kenshamir[m]: i've been really out of the loop on all these developments :(
18:04:05 <andytoshi> zkboo etc i'm sure you can do in secure hardware, and much faster than BPs even, but the resulting proofs are pretty big
18:04:11 <kenshamir[m]> <andytoshi "kenshamir: i've been really out "> Leave for a month and so many things happen :)
18:04:21 <andytoshi> hah right, i'm scrolling through all these 2020 citations
18:04:37 <andytoshi> and i'm like, i was busy this entire year, how did all y'all find time for this
18:04:51 <andytoshi> amazing how much manpower there is on this now
18:05:05 <kenshamir[m]> <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
18:05:18 <kenshamir[m]> Concrete efficiency
18:28:18 <mikerah[m]> https://eprint.iacr.org/2020/1536.pdf
18:28:25 <mikerah[m]> This just came out a hour ago
18:28:47 <mikerah[m]> You can replace the polynomial commitment scheme in Halo with anything even a FRI
18:30:55 <kenshamir[m]> <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
18:31:22 <kenshamir[m]> <mikerah[m] "https://eprint.iacr.org/2020/153"> This is exciting, I wonder what the advantages are to using this vs Halo2
18:32:05 <mikerah[m]> The advantages are problem more with respect to a particular usecase
18:32:46 <mikerah[m]> 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
18:32:51 <kenshamir[m]> Oh, they generalize the results to even FRI
18:33:49 <kenshamir[m]> I believe the interesting result from this paper, is that the PCS does not need to be efficient
18:34:32 <kenshamir[m]> <mikerah[m] "For example, in Monero, using Ha"> yeah Halo Infinite seems to be a more general construction, from reading the abstract
19:06:44 <sarang> Preprint on ring selection by some of the Omniring authors: https://eprint.iacr.org/2020/1550
23:12:03 <Inge-> 8
23:12:23 <Inge-> don't mind me.