# Proof-Carrying Data without Succinct Arguments paper
**URL:** https://forum.grin.mw/t/proof-carrying-data-without-succinct-arguments-paper/8207
**Category:** Research
**Created:** [January 8, 2021, 9:44am UTC](https://forum.grin.mw/t/proof-carrying-data-without-succinct-arguments-paper/8207 "2021-01-08T09:44:45Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@Anynomous](https://forum.grin.mw/u/Anynomous)
#### Post date: [January 8, 2021, 9:44am UTC](https://forum.grin.mw/t/proof-carrying-data-without-succinct-arguments-paper/8207/1 "2021-01-08T09:44:45Z")
This looks like an interesting paper. I only partly get the paper but it reads like it might be usefull for inspiration on building non-interactive transfers.
> **[1618.pdf](https://eprint.iacr.org/2020/1618.pdf)**
>
> 590.54 KB
---
### Author:  [@tromp](https://forum.grin.mw/u/tromp)
#### Post date: [March 29, 2021, 9:37am UTC](https://forum.grin.mw/t/proof-carrying-data-without-succinct-arguments-paper/8207/2 "2021-03-29T09:37:16Z")
It’s more useful for accelerating the Initial Bytes Download by using Incrementally Verified Computation to verify existence of a valid kernel history, without having to download all those kernels. I.e. it would make IBD just UTXO sized.
A more recent paper that might offer further improvements is
> **[370.pdf](https://eprint.iacr.org/2021/370.pdf)**
>
> 469.77 KB
---
### Author:  [@tromp](https://forum.grin.mw/u/tromp)
#### Post date: [August 11, 2022, 6:29am UTC](https://forum.grin.mw/t/proof-carrying-data-without-succinct-arguments-paper/8207/3 "2022-08-11T06:29:57Z")
STARKs can also be very useful in accelerating IBD, as John Davies pointed out on keybase:
> **[GitHub - lucidLuckylee/zerosync: Sync a Bitcoin full node using STARK-proofs](https://github.com/lucidLuckylee/zerosync)**
>
> Sync a Bitcoin full node using STARK-proofs. Contribute to lucidLuckylee/zerosync development by creating an account on GitHub.
---
### Author:  [@tromp](https://forum.grin.mw/u/tromp)
#### Post date: [October 11, 2022, 4:57pm UTC](https://forum.grin.mw/t/proof-carrying-data-without-succinct-arguments-paper/8207/4 "2022-10-11T16:57:18Z")
And this paper seems to address the challenge of Grin’s secp256k1 curve not being very FFT friendly:
[https://eccc.weizmann.ac.il/report/2022/110/](https://eccc.weizmann.ac.il/report/2022/110/)
---
### Author:  [@Anynomous](https://forum.grin.mw/u/Anynomous)
#### Post date: [October 12, 2022, 11:29am UTC](https://forum.grin.mw/t/proof-carrying-data-without-succinct-arguments-paper/8207/5 "2022-10-12T11:29:05Z")
> [@tromp](#):
>
> FFT friendly
What does FFT stand for, Fast Finit Field Transform or Fast Fourier transform? Maybe add a bit of context for the less mathematically gifted among us 😅 🙏
This is what I got after some digging,
> “Finite field cryptography” is fancy language for group-based cryptography done over the integers modulo a prime (instantiating a field) to distinguish this more “classic” approach from the new fancier elliptic curve cryptography."
Still no clue about why that is relevant for Grin, or if being able to do FFT with Grin creates new possibilities.
---
### Author:  [@tromp](https://forum.grin.mw/u/tromp)
#### Post date: [October 12, 2022, 6:59pm UTC](https://forum.grin.mw/t/proof-carrying-data-without-succinct-arguments-paper/8207/6 "2022-10-12T18:59:28Z")
FFT always stands for Fast Fourier Transform.
You can see one of the references make this explicit:
> [BCKL21] Eli Ben-Sasson, Dan Carmon, Swastik Kopparty, and David Levit. Elliptic curve fast fourier transform (ECFFT) part I: fast polynomial algorithms over all finite fields. Electron. Colloquium Comput.
> Complex., page 103, 2021.
The term FFT-friendly is a technical one that means having a subgroup of size 2^k. The larger k, the friendlier it is. For secp256k1, k=0 so it is as unfriendly as it gets:-(
There is no subgroup over which you can perform a (discrete) fast fourier transform.
I never heard of Fast Finite Field Transform but that would be FFFT, wouldn’t it?