sipa changed the topic of #bitcoin-wizards to: This channel is for discussing theoretical ideas with regard to cryptocurrencies, not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
greylica has quit []
davterra has joined #bitcoin-wizards
vtnerd_ has quit [Ping timeout: 260 seconds]
vtnerd_ has joined #bitcoin-wizards
davec has quit [Ping timeout: 258 seconds]
davec has joined #bitcoin-wizards
davec has quit [Ping timeout: 265 seconds]
davec has joined #bitcoin-wizards
CryptoDavid has quit [Quit: Connection closed for inactivity]
rusty has joined #bitcoin-wizards
ttc has joined #bitcoin-wizards
Belkaar has quit [Ping timeout: 264 seconds]
Belkaar_ has joined #bitcoin-wizards
helo has quit [Ping timeout: 260 seconds]
sunweaver1 has joined #bitcoin-wizards
arowser has joined #bitcoin-wizards
arowser has quit [Remote host closed the connection]
shesek has quit [Remote host closed the connection]
TheHoliestRoger has joined #bitcoin-wizards
justanotheruser has quit [Ping timeout: 256 seconds]
flag has quit [Quit: leaving]
flag has joined #bitcoin-wizards
DeanWeen has quit [Remote host closed the connection]
Dean_Guss has joined #bitcoin-wizards
proofofkeags has quit [Ping timeout: 265 seconds]
stiell has quit [Ping timeout: 246 seconds]
AaronvanW has quit [Remote host closed the connection]
justanotheruser has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
rusty has quit [Quit: Leaving.]
arowser has quit [Remote host closed the connection]
arowser has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 256 seconds]
AaronvanW has joined #bitcoin-wizards
them_ has quit []
ddustin has quit [Remote host closed the connection]
justanotheruser has quit [Ping timeout: 256 seconds]
OldMiner has joined #bitcoin-wizards
OldMiner has quit [Ping timeout: 240 seconds]
tromp has quit [Ping timeout: 272 seconds]
tromp has joined #bitcoin-wizards
tromp has quit [Read error: Connection reset by peer]
tromp has joined #bitcoin-wizards
rusty has joined #bitcoin-wizards
tromp_ has joined #bitcoin-wizards
tromp has quit [Ping timeout: 246 seconds]
stiell has joined #bitcoin-wizards
arowser has quit [Remote host closed the connection]
arowser has joined #bitcoin-wizards
arowser has quit [Remote host closed the connection]
arowser has joined #bitcoin-wizards
belcher_ has joined #bitcoin-wizards
marcoagner has joined #bitcoin-wizards
Antonet has joined #bitcoin-wizards
belcher has quit [Ping timeout: 256 seconds]
zmnscpxj_ has joined #bitcoin-wizards
TheoStorm has joined #bitcoin-wizards
TheoStorm has quit [Remote host closed the connection]
rusty has quit [Ping timeout: 258 seconds]
cbeams has quit [Read error: Connection reset by peer]
cbeams_ has joined #bitcoin-wizards
rusty has joined #bitcoin-wizards
arowser has quit [Remote host closed the connection]
arowser has joined #bitcoin-wizards
rusty has quit [Quit: Leaving.]
alice7 has joined #bitcoin-wizards
jonatack has quit [Ping timeout: 260 seconds]
<alice7>
Thoughts on Cairo by StarkWare? They claim that it scales general computation quite a bit. Could possible reduce both space/tx and cpu/tx as well as high level complexity for expressive contracts.
Antonet has quit []
<alice7>
What's the strongest argument against replacing on-chain pk crypto storage/verification with transparent zkps leveraging the PCP theorem?
<zmnscpxj_>
most such systems require proofs much larger than 64 bytes of signature
<alice7>
on proof can contain multiple txs though?
<alice7>
*one
<zmnscpxj_>
I have one proof that contains A, B, C, another proof that contains B, C, D, E, and yet another proof that contains C, D, E, F, G, can I merge them trivially?
davec has quit [Ping timeout: 246 seconds]
<alice7>
To the best of my understanding, not with Starks. That would require something like Halo2? But regardless, at scale, space is used more efficiently.
<zmnscpxj_>
yes, but how do you handle mempools?
<sipa>
you still need to transfer state uodates
<zmnscpxj_>
most of the bandwidth use of a fullnode is really tx relay
<zmnscpxj_>
not very compressible
<sipa>
i can imagine something where a miner creates an aggregate proof that says "i have verified all the transactions in this block"
<sipa>
which would replace the signatures, with a single, large proof
<alice7>
yes, that's what I'm imagining too
<zmnscpxj_>
but transferring individual txes would still require individual per-tx signatures at least, if my understanding is correct
<sipa>
but signatures aren't an overwhelming majority of the data
<sipa>
so it's a small constant factor data at best
davec has joined #bitcoin-wizards
<zmnscpxj_>
ah, most of it is in prevouts and scriptPubKeys?
<sipa>
not most
<zmnscpxj_>
what is the typical data then?
<sipa>
even if signatures are say 60%,it's a 2.5x bandwidth gain at best
<zmnscpxj_>
ah
<zmnscpxj_>
right
<sipa>
it may be a bigger cpu gain than that
nick_freeman has joined #bitcoin-wizards
<sipa>
but afaik the cost of constructing these proofs is huge... seconds, minutes
<zmnscpxj_>
Not going to work for miners
<sipa>
if they'rw feasible to make backward compatible at all
<alice7>
construction cost for proofs shouldn't be a problem for miners?
<sipa>
blocks must be constructible in... milliseconds ideally
<sipa>
maybe 10s or 100s of them
<alice7>
some fee construction should aline incentives
<alice7>
*align
<zmnscpxj_>
if you increase the fee/weight, then what would be the point?
<alice7>
thinking miners receive fees for generating proofs
<sipa>
once you reach seconds, you get nontrivial losses from forks
<zmnscpxj_>
in practice the whole point of doing this kind of things is to reduce fees for users
<zmnscpxj_>
so if you are going to increase the fees anyway, no user will run that softfork.
<alice7>
as long as the capacity gain is sufficient, incentives should reduce latency of proof generation long term. overall, fee/tx should be reduced
<sipa>
if the proof takes a minute (say), it's completely infeasible
<sipa>
i don't see what fees can compensate for that
<alice7>
shouldn't take minutes
<zmnscpxj_>
we could make blocks slower, like say every 100 minutes instead
<zmnscpxj_>
which lowers your tps anyway, so....
<sipa>
haha
<alice7>
for intergalactic transfers ;)
<alice7>
proof generation time is only a function of cpu tho, so it mostly depends on how much you spend on hardware
<zmnscpxj_>
reducing the amount of money I can spend on raw mining hashpower
<sipa>
maybe, i'm not familiar enough with this in particular
<sipa>
not all of these proof genrration techniques are equally parallellizable
davec has quit [Ping timeout: 265 seconds]
<sipa>
i think these ZKP techniques may one day prove useful, but more likely in a setting like a statechain/lightning thing, where a large update needs to be pushed on-chain
<sipa>
but they're all dumped as one transaction, with a proof that it is actually a correct aggregate of a huge number of offchain txn
<alice7>
yes, latency increase would make off-chain architecture even more relevant
davec has joined #bitcoin-wizards
<zmnscpxj_>
sipa: Potentially allowing for updates even if not all the participants are online, we hope?
<sipa>
as in that case there is nothing latency critical
sankarshan1 has joined #bitcoin-wizards
<alice7>
exactly
<zmnscpxj_>
the future is offchain
<sipa>
it could already be
<sipa>
we don't know ;)
<zmnscpxj_>
Consider a future where interplanetary commerce is being started. Would off-Earth economic interests tolerate having the blockchain centralized on Earth?
laptop has joined #bitcoin-wizards
zmnscpxj_ has quit [Remote host closed the connection]