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
elsimio has quit []
meepz has joined #bitcoin-wizards
rusty has quit [Quit: Leaving.]
IOMonster1 has joined #bitcoin-wizards
rjected has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 240 seconds]
<bitcoin-wizards3>
Zk rollup is a shift from using layer 2 as a data layer, to only using it as a computational layer. It improves space efficiency on layer 1 without risking centralization on layer 2.
tromp has quit [Remote host closed the connection]
tromp has joined #bitcoin-wizards
bitcoin-wizards3 has joined #bitcoin-wizards
bitcoin-wizards3 has quit [Client Quit]
nick_freeman has quit [Remote host closed the connection]
slivera has quit [Remote host closed the connection]
CubicEarth has quit [Ping timeout: 268 seconds]
nick_freeman has joined #bitcoin-wizards
nick_fre_ has joined #bitcoin-wizards
nick_freeman has quit [Ping timeout: 240 seconds]
bitdex has quit [Quit: = ""]
IGHOR has joined #bitcoin-wizards
CubicEarth has joined #bitcoin-wizards
pinheadmz has joined #bitcoin-wizards
pinheadmz has quit [Quit: pinheadmz]
Guyver2 has joined #bitcoin-wizards
rusty has quit [Quit: Leaving.]
son0p has joined #bitcoin-wizards
shush has joined #bitcoin-wizards
CryptoDavid has joined #bitcoin-wizards
shush has quit [Ping timeout: 240 seconds]
pinheadmz has joined #bitcoin-wizards
fnichol has quit []
francisco___ has quit [Quit: Connection closed for inactivity]
Stuk has joined #bitcoin-wizards
francisco___ has joined #bitcoin-wizards
<real_or_random>
https://eprint.iacr.org/2020/186.pdf sipa: this is related to your estimations on how many coins would be vulnerable to a quantum attacker
shesek has quit [Read error: Connection reset by peer]
shesek has joined #bitcoin-wizards
shesek has quit [Changing host]
shesek has joined #bitcoin-wizards
luke-jr has joined #bitcoin-wizards
mdunnio has joined #bitcoin-wizards
jungly has quit [Remote host closed the connection]
ddustin has joined #bitcoin-wizards
ddustin has quit [Ping timeout: 255 seconds]
Guyver2 has quit [Ping timeout: 268 seconds]
Guyver2_ has joined #bitcoin-wizards
Guyver2_ is now known as Guyver2
<yanmaani>
There is a discussion in the Monero IRC about using the BitTorrent DHT + brute-force to bootstrap nodes.
<yanmaani>
this removes the need for an initial seed node
<yanmaani>
any thoughts?
<kanzure>
bruteforce of what
<yanmaani>
ipv4
<yanmaani>
if there are 25 million bittorrent dht nodes, and 10% of these run on a predictable port, that gives 2^32/2500000 = 1718 tries on average to find a node
<yanmaani>
if 1 try = 1 UDP packet = 1500 bytes, that is 2.58 mb of data
Zenton has quit [Ping timeout: 260 seconds]
berndj has quit [Read error: Connection reset by peer]
berndj has joined #bitcoin-wizards
jungly has joined #bitcoin-wizards
ddustin has joined #bitcoin-wizards
shush has joined #bitcoin-wizards
shush has quit [Ping timeout: 258 seconds]
shush has joined #bitcoin-wizards
berndj has quit [Ping timeout: 260 seconds]
shush has quit [Remote host closed the connection]
_whitelogger has quit [Ping timeout: 248 seconds]
_whitelogger has joined #bitcoin-wizards
shush has joined #bitcoin-wizards
berndj has joined #bitcoin-wizards
nick_fre_ has quit [Remote host closed the connection]
nick_freeman has joined #bitcoin-wizards
shush has quit [Read error: Connection reset by peer]
shush has joined #bitcoin-wizards
Stuk has quit []
Jeremy_Rand_Talo has quit [Ping timeout: 248 seconds]
dl3br[m] has quit [Ping timeout: 256 seconds]
M7918070_[m] has quit [Ping timeout: 240 seconds]
mael-rolland[m] has quit [Ping timeout: 248 seconds]
zkao has quit [Ping timeout: 246 seconds]
charuto has quit [Ping timeout: 246 seconds]
TheFuzzStone[m] has quit [Ping timeout: 256 seconds]
Chris_Stewart_5 has quit [Ping timeout: 258 seconds]
Chris_Stewart_5 has joined #bitcoin-wizards
shush has quit [Remote host closed the connection]
<gleb>
yanmaani: take a look at "You Shall Not Join: A Measurement Study of Cryptocurrency Peer-to-Peer Bootstrapping Techniques". It's clueless in some aspectes, but with a basic understanding of Bitcoin's p2p you may derive some good conclusions from this work.
<gleb>
You may be interested in using ZMap for your "bruteforce".
<jeremyrubin>
bitcoin-wizards3: I don't think it does improve space efficiency of layer 1 appreciably in a utxo model. Maybe it's worth creating a single purpose account type of thing for ZKSync like applications, but I kind of doubt that would be popular. Short of that, CTV is a good design for Bitcoin.
<jeremyrubin>
Designing an account model for bitcoin would take years and even then unclear people would accept it
<jeremyrubin>
If you draft a BIP I'd review it though!
<jeremyrubin>
But without a concrete vision for how you'd do that, it's not a super fruitful conversation...
ddustin has quit [Remote host closed the connection]
ddustin has joined #bitcoin-wizards
ddustin has quit [Remote host closed the connection]
<yanmaani>
gleb: ZMap would be useful if I'm the only person doing it, but as a legitimate discovery mechanism bundling zmap is a bit over the top
ddustin has joined #bitcoin-wizards
ddustin has quit [Remote host closed the connection]
fox2p has quit [Ping timeout: 265 seconds]
zkao has joined #bitcoin-wizards
fox2p has joined #bitcoin-wizards
shush has joined #bitcoin-wizards
luke-jr has quit [Read error: Connection reset by peer]
jungly has quit [Remote host closed the connection]
luke-jr has joined #bitcoin-wizards
M7918070_[m] has joined #bitcoin-wizards
TheFuzzStone[m] has joined #bitcoin-wizards
mael-rolland[m] has joined #bitcoin-wizards
Jeremy_Rand_Talo has joined #bitcoin-wizards
dl3br[m] has joined #bitcoin-wizards
charuto has joined #bitcoin-wizards
bitcoin-wizards9 has joined #bitcoin-wizards
<bitcoin-wizards9>
jeremyrubin: CTV scaling discussion is missing the data availability perspective. Simply stating that a utxo model rollup don't increase on-chain space efficiency without providing any evidence seems pointless.
<jeremyrubin>
What does data availability mean
<kanzure>
bitcoin-wizards9: nah if the user doesn't have the UTXO then they haven't been paid; doesn't matter if it's allgedly been committed in a congestion control transaction.
<jeremyrubin>
The evidence is that they're both fundamentally O(N) if you want to pay O(N) addresses
<kanzure>
bitcoin-wizards9: so even if they had data unavailability the user wouldn't really care.. they just want their UTXO.
<jeremyrubin>
If you have a zk rollup you still need the data available somewhere
<kanzure>
bitcoin-wizards9: fastest way to get them their UTXO is to have a pool of pre-existing UTXOs with private keys that you plan to give away
shush has quit [Remote host closed the connection]
<jeremyrubin>
kanzure: That's not nescessarily true, you just need provable constructive receipt.
<jeremyrubin>
Also giving someone a private key (open dime model) is not great
<kanzure>
i agree it's not great, but in general users already trust exchanges to process withdrawal requests and complain when they don't get spendable coins anyway
<jeremyrubin>
The issue why that doesn't work is it's not forwardable
<jeremyrubin>
E.g., assume I trust you to not double spend the key. Then you give it to me. I can't xfer to someone else because they would need to trust me and the original holder
<jeremyrubin>
bitcoin-wizards9: you need to define what you mean by data availability
<jeremyrubin>
Surely someone has some data available, or they wouldn't know they got paid
<instagibbs>
AFAICT he means the data isn't available *on-chain*
<instagibbs>
?
<jeremyrubin>
(unclear if a he)
<jeremyrubin>
Yeah, but a ZK system will... also not have data available on chain
<jeremyrubin>
So it's not clear that state you don't need to store with a zk proof system that you would need to store with a CTV scheme that is problematic
<jeremyrubin>
Especially given that a full payout is O(N) in either case.
<jeremyrubin>
And not just O(N), it's not clear to me that CTV isn't spacewise cheaper as the constant can be smaller (depends on the zkproof scheme)
slivera has joined #bitcoin-wizards
CryptoDavid has quit [Quit: Connection closed for inactivity]
jungly has joined #bitcoin-wizards
Greedi has quit []
Zenton has joined #bitcoin-wizards
KindOne1 has joined #bitcoin-wizards
shush has joined #bitcoin-wizards
justanotheruser has quit [Ping timeout: 245 seconds]
bitcoin-wizards9 has joined #bitcoin-wizards
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
jungly has quit [Remote host closed the connection]
<bitcoin-wizards9>
The data availability problem arises when anything else than the secret key is required to authorize a spend, or prevent fraud.
<bitcoin-wizards9>
Layer 2 solutions that relies on off-chain data (available) must solve this problem and evidence shows that it leads to centralization.
<bitcoin-wizards9>
Zk Sync only requires the secret key to authorize a spend. Anyone can compute proofs and update the state.
<instagibbs>
that's really stretching the meaning of data availability problem. It's non-secret data you can back up anywhere.
<instagibbs>
pregenerated even
sipa has left #bitcoin-wizards [#bitcoin-wizards]
<jeremyrubin>
But with ZKSync you have to know what the last state is to update to a new one, right?
<bitcoin-wizards9>
State is published on-chain.
<jeremyrubin>
What
<jeremyrubin>
So you have do an on chain tx for every update?
<jeremyrubin>
And it's O(N) each time?
<bitcoin-wizards9>
Correct
<bitcoin-wizards9>
O(N)?
<jeremyrubin>
If it's a state covering N users, it must be O(N) sized
<bitcoin-wizards9>
Its only a proof
<jeremyrubin>
So then where is the statement that the proof proves?
<jeremyrubin>
And how is that not subject to the data availability issue?
<jeremyrubin>
e.g., I can do OP_IF <n of n multisig OP_ELSE <h> CTV OP_ENDIF
<jeremyrubin>
And just do a txn per block updating states
<jeremyrubin>
This sounds equivalent to what your ZKSync is doing.
<jeremyrubin>
The CTV is the "proof", and the multisig allows everyone to update
<jeremyrubin>
The only difference is if "anyone" can update, or if "everyone" has to update
bitdex has joined #bitcoin-wizards
<bitcoin-wizards9>
Its one commit tx and one proof tx, check zksync.io
<jeremyrubin>
Ok but who is holding on to the *Statements* that you are proving?
<jeremyrubin>
So that peg-out can occur?
<jeremyrubin>
E.g., if my state is a mapping of address to amount
<jeremyrubin>
and a sequence number
<jeremyrubin>
And I prove for each transition an authorized transition for that sequence number
<jeremyrubin>
THe mapping and sequence can be maintained off chain
<jeremyrubin>
But you have a data availability issue similar in nature
<bitcoin-wizards9>
Statement is on-chain, so there is no data avilability problem
<jeremyrubin>
Ok if the statement is on chain what's the scalability benefit
<jeremyrubin>
Constant facotr?
<jeremyrubin>
You're just ZK'ing the signatures?
<bitcoin-wizards9>
Space savings deoends on proving time
<jeremyrubin>
But you agree it's at best a constant factor
<jeremyrubin>
Because statements are on-chain completely
<bitcoin-wizards9>
size grows linearly as far as I can tell, yes
<jeremyrubin>
Ok
<jeremyrubin>
So here's how you solve data availability with CTV:
<jeremyrubin>
Commit (in the CTV txn) to the plaintext address to amount structure.
<jeremyrubin>
It's now O(N) per txn, like ZK Rollup, but doesn't create O(N) outputs per step
<jeremyrubin>
Further, you can probably compress the data to just be O(updates) sized rather than O(all accounts) per step
<bitcoin-wizards9>
Yes, but the space efficiency is better with a zkp, so why not use it?
<jeremyrubin>
No it isn't
<jeremyrubin>
How is the ZKP better if you're requiring the state be available on-chain
<jeremyrubin>
the ZKP is just for making *signatures* smaller as you've described it
justanotheruser has joined #bitcoin-wizards
<bitcoin-wizards9>
The more you increase proof generation time, the shorter the proof
<jeremyrubin>
I'm not talking about the proof
<jeremyrubin>
Assume a proof oracle that can be queried in O(1)
<jeremyrubin>
you are making a claim about data availability
<jeremyrubin>
Which implies O(N) stuff on chain
<jeremyrubin>
Or at least O(updates)
<jeremyrubin>
the proofs of those updates can be zero cost
<jeremyrubin>
The primary thing you're doubting about CTV is the on chain data availability
<jeremyrubin>
But that's a completely ortho concern
<bitcoin-wizards9>
ortho concern?
<kanzure>
orthogonal
<jeremyrubin>
To be clear, I agree there's a benefit to putting the data on chain available and creating 1 output, as it's easier to update the states from that point on.
<jeremyrubin>
But it's not something unique to ZKSync, all that ZKSync is is a way of making more compact signatures.
<jeremyrubin>
Which is great!
<bitcoin-wizards9>
Utxo based Zk rollup would probably need something like CTV to start with..
<jeremyrubin>
But you could imagine OP_IF <zksync> OP_ELSE <H> OP_CTV OP_ENDIF
shush has quit [Read error: Connection reset by peer]
<jeremyrubin>
bitcoin-wizards9: Ok, so then what's your objection to CTV?
<jeremyrubin>
CTV is a building block
shush has joined #bitcoin-wizards
<jeremyrubin>
If you think utxo based zk rollup needs CTV, better motivation for CTV
<bitcoin-wizards9>
If a solution to the data avilability problem is addressed in CTV, I believe it would have a stronger argument
<jeremyrubin>
Ok -- but that's sort of different?
<jeremyrubin>
Just add an op_return if you want on chain data availability
<jeremyrubin>
(btw -- there's no such thing as on-chain data availability; all nodes can prune old blocks)
mdunnio has quit [Remote host closed the connection]