--- Log opened Fri Feb 21 00:00:59 2020 00:05 -!- tromp_ [~tromp@2a02:a210:ca3:2800:d67:fbb5:f12:1ea5] has joined #bitcoin-wizards 00:08 -!- tromp [~tromp@2a02:a210:ca3:2800:4bd:103e:e73e:444f] has quit [Ping timeout: 272 seconds] 00:15 -!- IGHOR [~quassel@93.178.216.72] has quit [Ping timeout: 272 seconds] 00:23 -!- rjected [~rjected@50-204-66-177-static.hfc.comcastbusiness.net] has quit [Ping timeout: 240 seconds] 00:25 -!- tromp_ [~tromp@2a02:a210:ca3:2800:d67:fbb5:f12:1ea5] has quit [Remote host closed the connection] 00:31 -!- marcoagner [~user@bl11-16-246.dsl.telepac.pt] has joined #bitcoin-wizards 00:38 -!- tromp [~tromp@2a02:a210:ca3:2800:d67:fbb5:f12:1ea5] has joined #bitcoin-wizards 00:42 -!- vdo [~vdo1138@108.61.209.80] has joined #bitcoin-wizards 00:42 -!- vdo [~vdo1138@108.61.209.80] has quit [Changing host] 00:42 -!- vdo [~vdo1138@unaffiliated/vdo] has joined #bitcoin-wizards 01:00 -!- kutio [~kutio@141.98.101.133] has quit [] 01:18 -!- shazow [~shazow@195.206.169.238] has joined #bitcoin-wizards 01:22 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards 01:54 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 255 seconds] 01:55 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-wizards 02:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards 02:19 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 268 seconds] 02:25 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 02:28 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-wizards 02:47 -!- nick_freeman [~nick_free@2001:16b8:309a:e400:60e9:9916:9fe6:6040] has joined #bitcoin-wizards 03:00 -!- tromp [~tromp@2a02:a210:ca3:2800:d67:fbb5:f12:1ea5] has quit [Remote host closed the connection] 03:03 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 258 seconds] 03:07 -!- tromp [~tromp@2a02:a210:ca3:2800:d67:fbb5:f12:1ea5] has joined #bitcoin-wizards 03:11 -!- nick_freeman [~nick_free@2001:16b8:309a:e400:60e9:9916:9fe6:6040] has quit [Remote host closed the connection] 03:15 -!- nick_freeman [~nick_free@2001:16b8:309a:e400:60e9:9916:9fe6:6040] has joined #bitcoin-wizards 03:18 -!- nick_freeman [~nick_free@2001:16b8:309a:e400:60e9:9916:9fe6:6040] has quit [Remote host closed the connection] 03:18 -!- nick_freeman [~nick_free@2001:16b8:309a:e400:60e9:9916:9fe6:6040] has joined #bitcoin-wizards 03:20 -!- nick_freeman [~nick_free@2001:16b8:309a:e400:60e9:9916:9fe6:6040] has quit [Remote host closed the connection] 03:20 -!- nick_freeman [~nick_free@2001:16b8:309a:e400:60e9:9916:9fe6:6040] has joined #bitcoin-wizards 03:37 -!- harrigan_ [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Read error: Connection reset by peer] 03:38 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-wizards 03:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards 03:47 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards 04:00 -!- shazow [~shazow@195.206.169.238] has quit [] 04:00 -!- bitcoin-wizards3 [3e71c29d@gateway/web/cgi-irc/kiwiirc.com/ip.62.113.194.157] has joined #bitcoin-wizards 04:00 < bitcoin-wizards3> Right, so a utxo zk rollup would not be as straight forward as zkSync. 04:01 < bitcoin-wizards3> Addresses are derived from the secret key, not sure how that would affect pruning. 04:07 -!- meepz [4c6d71f7@gateway/web/cgi-irc/kiwiirc.com/ip.76.109.113.247] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 04:12 < bitcoin-wizards3> Still no change in data availability assumptions though, assuming archival nodes are not abandoned. 04:13 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer] 04:14 -!- shesek [~shesek@185.3.145.161] has joined #bitcoin-wizards 04:14 -!- shesek [~shesek@185.3.145.161] has quit [Changing host] 04:14 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-wizards 04:17 -!- nick_freeman [~nick_free@2001:16b8:309a:e400:60e9:9916:9fe6:6040] has quit [Remote host closed the connection] 04:18 -!- fnichol [~fnichol@195.206.169.238] has joined #bitcoin-wizards 04:22 -!- bitcoin-wizards3 [3e71c29d@gateway/web/cgi-irc/kiwiirc.com/ip.62.113.194.157] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 04:23 -!- bitcoin-wizards3 [3e71c29d@gateway/web/cgi-irc/kiwiirc.com/ip.62.113.194.157] has joined #bitcoin-wizards 04:24 -!- nick_freeman [~nick_free@2001:16b8:309a:e400:60e9:9916:9fe6:6040] has joined #bitcoin-wizards 04:28 < 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. 04:37 -!- meepz [49f5d61c@gateway/web/cgi-irc/kiwiirc.com/ip.73.245.214.28] has joined #bitcoin-wizards 04:38 -!- bitcoin-wizards3 [3e71c29d@gateway/web/cgi-irc/kiwiirc.com/ip.62.113.194.157] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 04:54 -!- tromp [~tromp@2a02:a210:ca3:2800:d67:fbb5:f12:1ea5] has quit [Remote host closed the connection] 04:55 -!- tromp [~tromp@2a02:a210:ca3:2800:d67:fbb5:f12:1ea5] has joined #bitcoin-wizards 05:14 -!- bitcoin-wizards3 [3e71c24b@gateway/web/cgi-irc/kiwiirc.com/ip.62.113.194.75] has joined #bitcoin-wizards 05:14 -!- bitcoin-wizards3 [3e71c24b@gateway/web/cgi-irc/kiwiirc.com/ip.62.113.194.75] has quit [Client Quit] 05:21 -!- nick_freeman [~nick_free@2001:16b8:309a:e400:60e9:9916:9fe6:6040] has quit [Remote host closed the connection] 05:25 -!- slivera [~slivera@217.138.204.105] has quit [Remote host closed the connection] 05:28 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 268 seconds] 05:36 -!- nick_freeman [~nick_free@2001:16b8:309a:e400:60e9:9916:9fe6:6040] has joined #bitcoin-wizards 05:36 -!- nick_fre_ [~nick_free@2001:16b8:309a:e400:b8fa:eac4:7d0a:3b38] has joined #bitcoin-wizards 05:40 -!- nick_freeman [~nick_free@2001:16b8:309a:e400:60e9:9916:9fe6:6040] has quit [Ping timeout: 240 seconds] 05:55 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 05:56 -!- IGHOR [~quassel@93.178.216.72] has joined #bitcoin-wizards 05:58 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #bitcoin-wizards 05:59 -!- pinheadmz [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-wizards 06:14 -!- pinheadmz [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Quit: pinheadmz] 06:16 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-wizards 06:21 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 06:26 -!- son0p [~son0p@181.58.38.54] has joined #bitcoin-wizards 06:28 -!- shush [~pawn@2605:e000:1c02:c564:567:feb9:9e54:39be] has joined #bitcoin-wizards 06:29 -!- CryptoDavid [uid14990@gateway/web/irccloud.com/x-hzsaepfhryugcklp] has joined #bitcoin-wizards 06:33 -!- shush [~pawn@2605:e000:1c02:c564:567:feb9:9e54:39be] has quit [Ping timeout: 240 seconds] 06:56 -!- pinheadmz [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-wizards 07:00 -!- fnichol [~fnichol@195.206.169.238] has quit [] 07:02 -!- francisco___ [uid418144@gateway/web/irccloud.com/x-sjfsreijckoftuop] has quit [Quit: Connection closed for inactivity] 07:18 -!- Stuk [~Stuk@185.169.255.76] has joined #bitcoin-wizards 07:38 -!- francisco___ [uid418144@gateway/web/irccloud.com/x-evfawdohgdgmmvek] has joined #bitcoin-wizards 07:44 < 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 08:14 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 08:14 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer] 08:14 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-wizards 08:15 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-wizards 08:19 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-wizards 08:29 -!- jungly [~jungly@79.8.200.97] has quit [Remote host closed the connection] 08:35 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-wizards 08:40 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 255 seconds] 08:41 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 268 seconds] 08:44 -!- Guyver2_ [Guyver@guyver2.xs4all.nl] has joined #bitcoin-wizards 08:48 -!- Guyver2_ is now known as Guyver2 08:53 < yanmaani> There is a discussion in the Monero IRC about using the BitTorrent DHT + brute-force to bootstrap nodes. 08:53 < yanmaani> this removes the need for an initial seed node 08:53 < yanmaani> any thoughts? 08:54 < kanzure> bruteforce of what 08:55 < yanmaani> ipv4 08:56 < 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 08:57 < yanmaani> if 1 try = 1 UDP packet = 1500 bytes, that is 2.58 mb of data 08:59 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 260 seconds] 09:05 -!- berndj [~berndj@azna.co.za] has quit [Read error: Connection reset by peer] 09:06 -!- berndj [~berndj@azna.co.za] has joined #bitcoin-wizards 09:14 -!- jungly [~jungly@host237-31-dynamic.249-95-r.retail.telecomitalia.it] has joined #bitcoin-wizards 09:17 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-wizards 09:17 -!- shush [~pawn@173.227.31.130] has joined #bitcoin-wizards 09:22 -!- shush [~pawn@173.227.31.130] has quit [Ping timeout: 258 seconds] 09:32 -!- shush [~pawn@173.227.31.130] has joined #bitcoin-wizards 09:36 -!- berndj [~berndj@azna.co.za] has quit [Ping timeout: 260 seconds] 09:44 -!- shush [~pawn@173.227.31.130] has quit [Remote host closed the connection] 09:45 -!- _whitelogger [~whitelogg@uruz.whitequark.org] has quit [Ping timeout: 248 seconds] 09:47 -!- jungly [~jungly@host237-31-dynamic.249-95-r.retail.telecomitalia.it] has quit [Remote host closed the connection] 09:47 -!- _whitelogger [~whitelogg@uruz.whitequark.org] has joined #bitcoin-wizards 09:49 -!- shush [~pawn@173.227.31.130] has joined #bitcoin-wizards 09:50 -!- berndj [~berndj@197.242.93.82] has joined #bitcoin-wizards 09:50 -!- nick_fre_ [~nick_free@2001:16b8:309a:e400:b8fa:eac4:7d0a:3b38] has quit [Remote host closed the connection] 09:51 -!- nick_freeman [~nick_free@2001:16b8:309a:e400:b8fa:eac4:7d0a:3b38] has joined #bitcoin-wizards 09:59 -!- shush [~pawn@173.227.31.130] has quit [Read error: Connection reset by peer] 09:59 -!- shush [~pawn@173.227.31.130] has joined #bitcoin-wizards 10:00 -!- Stuk [~Stuk@185.169.255.76] has quit [] 10:11 -!- Jeremy_Rand_Talo [jeremyra1@gateway/shell/matrix.org/x-tdrxgspccxroisrp] has quit [Ping timeout: 248 seconds] 10:11 -!- dl3br[m] [dlebrechtm@gateway/shell/matrix.org/x-gojolywldkrmnsxn] has quit [Ping timeout: 256 seconds] 10:12 -!- M7918070_[m] [m7918070ma@gateway/shell/matrix.org/x-oiyhstejuwchujbw] has quit [Ping timeout: 240 seconds] 10:12 -!- mael-rolland[m] [mael-rolla@gateway/shell/matrix.org/x-hybbornnfndepota] has quit [Ping timeout: 248 seconds] 10:12 -!- zkao [zkaomatrix@gateway/shell/matrix.org/x-rnyyhmualxeninuy] has quit [Ping timeout: 246 seconds] 10:12 -!- charuto [charutocaf@gateway/shell/matrix.org/x-yidsswxhwnjivgeo] has quit [Ping timeout: 246 seconds] 10:12 -!- TheFuzzStone[m] [thefuzzsto@gateway/shell/matrix.org/x-pvuhrdptiepzivku] has quit [Ping timeout: 256 seconds] 10:18 -!- Greedi [~Greedi@141.98.101.133] has joined #bitcoin-wizards 10:19 -!- jungly [~jungly@host237-31-dynamic.249-95-r.retail.telecomitalia.it] has joined #bitcoin-wizards 10:20 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 10:21 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-wizards 10:21 -!- son0p [~son0p@181.58.38.54] has quit [Ping timeout: 258 seconds] 10:25 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds] 10:29 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards 10:40 -!- shush [~pawn@173.227.31.130] has quit [Remote host closed the connection] 10:42 < 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. 10:43 < gleb> You may be interested in using ZMap for your "bruteforce". 10:51 < 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. 10:51 < jeremyrubin> Designing an account model for bitcoin would take years and even then unclear people would accept it 10:52 < jeremyrubin> If you draft a BIP I'd review it though! 10:52 < jeremyrubin> But without a concrete vision for how you'd do that, it's not a super fruitful conversation... 11:02 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection] 11:03 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-wizards 11:03 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection] 11:03 < 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 11:03 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-wizards 11:04 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection] 11:04 -!- fox2p [~fox2p@cpe-66-108-32-173.nyc.res.rr.com] has quit [Ping timeout: 265 seconds] 11:04 -!- zkao [zkaomatrix@gateway/shell/matrix.org/x-ywhnpfdsdigvnjuo] has joined #bitcoin-wizards 11:06 -!- fox2p [~fox2p@cpe-66-108-32-173.nyc.res.rr.com] has joined #bitcoin-wizards 11:19 -!- shush [~pawn@173.227.31.130] has joined #bitcoin-wizards 11:31 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer] 11:31 -!- jungly [~jungly@host237-31-dynamic.249-95-r.retail.telecomitalia.it] has quit [Remote host closed the connection] 11:32 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-wizards 11:44 -!- M7918070_[m] [m7918070ma@gateway/shell/matrix.org/x-jaiurjcnonzdkett] has joined #bitcoin-wizards 11:44 -!- mael-rolland[m] [mael-rolla@gateway/shell/matrix.org/x-adzduddjimlutgdi] has joined #bitcoin-wizards 11:44 -!- Jeremy_Rand_Talo [jeremyra1@gateway/shell/matrix.org/x-bgbkqirdtacddzvz] has joined #bitcoin-wizards 11:44 -!- TheFuzzStone[m] [thefuzzsto@gateway/shell/matrix.org/x-ifrytzihknwjwjho] has joined #bitcoin-wizards 11:44 -!- dl3br[m] [dlebrechtm@gateway/shell/matrix.org/x-ebvonczxuarmmjpg] has joined #bitcoin-wizards 11:44 -!- charuto [charutocaf@gateway/shell/matrix.org/x-wznqketysyhbpexa] has joined #bitcoin-wizards 11:53 -!- bitcoin-wizards9 [3e71c24b@gateway/web/cgi-irc/kiwiirc.com/ip.62.113.194.75] has joined #bitcoin-wizards 11:55 < 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. 11:56 < jeremyrubin> What does data availability mean 11:57 < 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. 11:57 < jeremyrubin> The evidence is that they're both fundamentally O(N) if you want to pay O(N) addresses 11:57 < kanzure> bitcoin-wizards9: so even if they had data unavailability the user wouldn't really care.. they just want their UTXO. 11:57 < jeremyrubin> If you have a zk rollup you still need the data available somewhere 11:57 < 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 11:58 -!- shush [~pawn@173.227.31.130] has quit [Remote host closed the connection] 11:59 < jeremyrubin> kanzure: That's not nescessarily true, you just need provable constructive receipt. 12:00 < jeremyrubin> Also giving someone a private key (open dime model) is not great 12:00 < 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 12:01 < jeremyrubin> The issue why that doesn't work is it's not forwardable 12:02 < 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 12:04 < jeremyrubin> bitcoin-wizards9: you need to define what you mean by data availability 12:04 < jeremyrubin> Surely someone has some data available, or they wouldn't know they got paid 12:04 -!- bitcoin-wizards9 [3e71c24b@gateway/web/cgi-irc/kiwiirc.com/ip.62.113.194.75] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 12:10 < instagibbs> AFAICT he means the data isn't available *on-chain* 12:10 < instagibbs> ? 12:10 < jeremyrubin> (unclear if a he) 12:11 < jeremyrubin> Yeah, but a ZK system will... also not have data available on chain 12:12 < 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 12:12 < jeremyrubin> Especially given that a full payout is O(N) in either case. 12:13 < 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) 12:45 -!- slivera [~slivera@103.77.232.147] has joined #bitcoin-wizards 12:46 -!- CryptoDavid [uid14990@gateway/web/irccloud.com/x-hzsaepfhryugcklp] has quit [Quit: Connection closed for inactivity] 12:50 -!- jungly [~jungly@host237-31-dynamic.249-95-r.retail.telecomitalia.it] has joined #bitcoin-wizards 13:00 -!- Greedi [~Greedi@141.98.101.133] has quit [] 13:08 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-wizards 13:18 -!- KindOne1 [~KindOne@195.206.183.79] has joined #bitcoin-wizards 13:31 -!- shush [~pawn@173.227.31.130] has joined #bitcoin-wizards 13:32 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 245 seconds] 13:33 -!- bitcoin-wizards9 [3e71c231@gateway/web/cgi-irc/kiwiirc.com/ip.62.113.194.49] has joined #bitcoin-wizards 13:45 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 13:50 -!- jungly [~jungly@host237-31-dynamic.249-95-r.retail.telecomitalia.it] has quit [Remote host closed the connection] 14:04 -!- bitcoin-wizards9 [3e71c231@gateway/web/cgi-irc/kiwiirc.com/ip.62.113.194.49] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 14:08 -!- bitcoin-wizards9 [3e71c231@gateway/web/cgi-irc/kiwiirc.com/ip.62.113.194.49] has joined #bitcoin-wizards 14:09 < bitcoin-wizards9> The data availability problem arises when anything else than the secret key is required to authorize a spend, or prevent fraud. 14:10 < bitcoin-wizards9> Layer 2 solutions that relies on off-chain data (available) must solve this problem and evidence shows that it leads to centralization. 14:11 < bitcoin-wizards9> Zk Sync only requires the secret key to authorize a spend. Anyone can compute proofs and update the state. 14:14 < instagibbs> that's really stretching the meaning of data availability problem. It's non-secret data you can back up anywhere. 14:14 < instagibbs> pregenerated even 14:18 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has left #bitcoin-wizards [] 14:20 < jeremyrubin> But with ZKSync you have to know what the last state is to update to a new one, right? 14:21 < bitcoin-wizards9> State is published on-chain. 14:21 < jeremyrubin> What 14:21 < jeremyrubin> So you have do an on chain tx for every update? 14:22 < jeremyrubin> And it's O(N) each time? 14:22 < bitcoin-wizards9> Correct 14:22 < bitcoin-wizards9> O(N)? 14:22 < jeremyrubin> If it's a state covering N users, it must be O(N) sized 14:23 < bitcoin-wizards9> Its only a proof 14:23 < jeremyrubin> So then where is the statement that the proof proves? 14:23 < jeremyrubin> And how is that not subject to the data availability issue? 14:24 < jeremyrubin> e.g., I can do OP_IF CTV OP_ENDIF 14:24 < jeremyrubin> And just do a txn per block updating states 14:24 < jeremyrubin> This sounds equivalent to what your ZKSync is doing. 14:25 < jeremyrubin> The CTV is the "proof", and the multisig allows everyone to update 14:25 < jeremyrubin> The only difference is if "anyone" can update, or if "everyone" has to update 14:25 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-wizards 14:26 < bitcoin-wizards9> Its one commit tx and one proof tx, check zksync.io 14:27 < jeremyrubin> Ok but who is holding on to the *Statements* that you are proving? 14:27 < jeremyrubin> So that peg-out can occur? 14:28 < jeremyrubin> E.g., if my state is a mapping of address to amount 14:28 < jeremyrubin> and a sequence number 14:28 < jeremyrubin> And I prove for each transition an authorized transition for that sequence number 14:28 < jeremyrubin> THe mapping and sequence can be maintained off chain 14:28 < jeremyrubin> But you have a data availability issue similar in nature 14:30 < bitcoin-wizards9> Statement is on-chain, so there is no data avilability problem 14:30 < jeremyrubin> Ok if the statement is on chain what's the scalability benefit 14:30 < jeremyrubin> Constant facotr? 14:30 < jeremyrubin> You're just ZK'ing the signatures? 14:31 < bitcoin-wizards9> Space savings deoends on proving time 14:31 < jeremyrubin> But you agree it's at best a constant factor 14:31 < jeremyrubin> Because statements are on-chain completely 14:32 < bitcoin-wizards9> size grows linearly as far as I can tell, yes 14:32 < jeremyrubin> Ok 14:32 < jeremyrubin> So here's how you solve data availability with CTV: 14:33 < jeremyrubin> Commit (in the CTV txn) to the plaintext address to amount structure. 14:34 < jeremyrubin> It's now O(N) per txn, like ZK Rollup, but doesn't create O(N) outputs per step 14:34 < jeremyrubin> Further, you can probably compress the data to just be O(updates) sized rather than O(all accounts) per step 14:35 < bitcoin-wizards9> Yes, but the space efficiency is better with a zkp, so why not use it? 14:35 < jeremyrubin> No it isn't 14:36 < jeremyrubin> How is the ZKP better if you're requiring the state be available on-chain 14:36 < jeremyrubin> the ZKP is just for making *signatures* smaller as you've described it 14:37 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-wizards 14:38 < bitcoin-wizards9> The more you increase proof generation time, the shorter the proof 14:38 < jeremyrubin> I'm not talking about the proof 14:39 < jeremyrubin> Assume a proof oracle that can be queried in O(1) 14:39 < jeremyrubin> you are making a claim about data availability 14:39 < jeremyrubin> Which implies O(N) stuff on chain 14:40 < jeremyrubin> Or at least O(updates) 14:40 < jeremyrubin> the proofs of those updates can be zero cost 14:41 < jeremyrubin> The primary thing you're doubting about CTV is the on chain data availability 14:41 < jeremyrubin> But that's a completely ortho concern 14:42 < bitcoin-wizards9> ortho concern? 14:42 < kanzure> orthogonal 14:43 < 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. 14:44 < jeremyrubin> But it's not something unique to ZKSync, all that ZKSync is is a way of making more compact signatures. 14:44 < jeremyrubin> Which is great! 14:44 < bitcoin-wizards9> Utxo based Zk rollup would probably need something like CTV to start with.. 14:44 < jeremyrubin> But you could imagine OP_IF OP_ELSE OP_CTV OP_ENDIF 14:44 -!- shush [~pawn@173.227.31.130] has quit [Read error: Connection reset by peer] 14:44 < jeremyrubin> bitcoin-wizards9: Ok, so then what's your objection to CTV? 14:45 < jeremyrubin> CTV is a building block 14:45 -!- shush [~pawn@173.227.31.130] has joined #bitcoin-wizards 14:45 < jeremyrubin> If you think utxo based zk rollup needs CTV, better motivation for CTV 14:46 < bitcoin-wizards9> If a solution to the data avilability problem is addressed in CTV, I believe it would have a stronger argument 14:48 < jeremyrubin> Ok -- but that's sort of different? 14:48 < jeremyrubin> Just add an op_return if you want on chain data availability 14:49 < jeremyrubin> (btw -- there's no such thing as on-chain data availability; all nodes can prune old blocks) 14:59 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection] 15:04 -!- bitcoin-wizards9 [3e71c231@gateway/web/cgi-irc/kiwiirc.com/ip.62.113.194.49] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 15:09 -!- bitcoin-wizards9 [3e71c231@gateway/web/cgi-irc/kiwiirc.com/ip.62.113.194.49] has joined #bitcoin-wizards 15:15 -!- bitcoin-wizards9 [3e71c231@gateway/web/cgi-irc/kiwiirc.com/ip.62.113.194.49] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 15:39 -!- shush [~pawn@173.227.31.130] has quit [Remote host closed the connection] 15:39 -!- shush [~pawn@173.227.31.130] has joined #bitcoin-wizards 15:50 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 15:53 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds] 16:00 -!- KindOne1 [~KindOne@195.206.183.79] has quit [] 16:04 -!- slivera [~slivera@103.77.232.147] has quit [Quit: Leaving] 16:09 -!- shush [~pawn@173.227.31.130] has quit [Remote host closed the connection] 16:09 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 248 seconds] 16:16 -!- shush [~pawn@173.227.31.130] has joined #bitcoin-wizards 16:16 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 16:17 -!- ensky [~ensky@89.249.74.213] has joined #bitcoin-wizards 16:28 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-wizards 16:33 -!- nirved [~nirved@2a02:8071:b58a:3c00:3ca6:9fb9:2e23:4e12] has quit [Read error: Connection reset by peer] 16:38 -!- Noldorin [~noldorin@unaffiliated/noldorin] has joined #bitcoin-wizards 16:41 -!- Noldorin [~noldorin@unaffiliated/noldorin] has quit [Client Quit] 16:41 -!- marcoagner [~user@bl11-16-246.dsl.telepac.pt] has quit [Ping timeout: 268 seconds] 16:43 -!- yanmaani [~yanmaani@gateway/tor-sasl/m7918070m1/x-47480619] has quit [Ping timeout: 240 seconds] 16:52 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards 16:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 258 seconds] 17:04 -!- grubles_ is now known as dingus 17:08 -!- shush [~pawn@173.227.31.130] has quit [Remote host closed the connection] 17:08 -!- nirved [~nirved@2a02:8071:b58a:3c00:3ca6:9fb9:2e23:4e12] has joined #bitcoin-wizards 17:12 -!- superkuh [~superkuh@unaffiliated/superkuh] has quit [Read error: Connection reset by peer] 17:13 -!- shush [~pawn@173.227.31.130] has joined #bitcoin-wizards 17:14 -!- shush [~pawn@173.227.31.130] has quit [Remote host closed the connection] 17:18 -!- tromp [~tromp@2a02:a210:ca3:2800:d67:fbb5:f12:1ea5] has quit [Remote host closed the connection] 17:21 < asukan> On-chain data availability is based on the assumption that miners will broadcast new blocks as fast as they can and there're always some ondes keep a full history imo 17:22 -!- superkuh [~superkuh@unaffiliated/superkuh] has joined #bitcoin-wizards 17:26 -!- surja795 [uid422261@gateway/web/irccloud.com/x-lvahpiaoigdfxpgk] has quit [Quit: Connection closed for inactivity] 17:30 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-wizards 17:32 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Read error: Connection reset by peer] 17:36 -!- nick_freeman [~nick_free@2001:16b8:309a:e400:b8fa:eac4:7d0a:3b38] has quit [Remote host closed the connection] 17:44 -!- nick_freeman [~nick_free@2001:16b8:309a:e400:b8fa:eac4:7d0a:3b38] has joined #bitcoin-wizards 17:49 -!- nick_freeman [~nick_free@2001:16b8:309a:e400:b8fa:eac4:7d0a:3b38] has quit [Ping timeout: 272 seconds] 17:51 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-wizards 17:55 -!- tromp [~tromp@2a02:a210:ca3:2800:d67:fbb5:f12:1ea5] has joined #bitcoin-wizards 18:00 -!- tromp [~tromp@2a02:a210:ca3:2800:d67:fbb5:f12:1ea5] has quit [Ping timeout: 272 seconds] 18:00 -!- meepz [49f5d61c@gateway/web/cgi-irc/kiwiirc.com/ip.73.245.214.28] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 18:05 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 18:14 -!- tromp [~tromp@2a02:a210:ca3:2800:40fe:1b7b:7c1a:4d68] has joined #bitcoin-wizards 18:18 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds] 18:18 -!- tromp [~tromp@2a02:a210:ca3:2800:40fe:1b7b:7c1a:4d68] has quit [Ping timeout: 272 seconds] 18:23 < jeremyrubin> asukan: you may want to catch up on the context of the conversation. It's about if on-chain availability is an important property over off-chain availability 18:23 < jeremyrubin> Off chain availability can be more available than on chain 18:23 < jeremyrubin> So on chain availability isn't a fantastic solution (e.g., if you rely on on-chain availability from random nodes you really want to lose your txns in a reorg?) 18:32 -!- Belkaar [~Belkaar@unaffiliated/belkaar] has quit [Ping timeout: 258 seconds] 18:33 -!- Belkaar [~Belkaar@xdsl-87-78-93-45.nc.de] has joined #bitcoin-wizards 18:33 -!- Belkaar [~Belkaar@xdsl-87-78-93-45.nc.de] has quit [Changing host] 18:33 -!- Belkaar [~Belkaar@unaffiliated/belkaar] has joined #bitcoin-wizards 18:41 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Read error: Connection reset by peer] 18:51 -!- jimmysong [~jimmysong@209.194.241.15] has joined #bitcoin-wizards 18:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards 18:53 < asukan> I was referring to "all nodes can prune old blocks" and make sense of using layer 1 as a data availability layer 18:54 < asukan> Re-org is not an issue if you only consider data on-chain after X blocks 19:00 -!- ensky [~ensky@89.249.74.213] has quit [] 19:00 < asukan> I agree that ZK rollup doesn't reduce on-chain state 19:18 -!- bayashi [~bayashi@139.28.218.198] has joined #bitcoin-wizards 19:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 19:56 -!- pinheadmz [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Quit: pinheadmz] 20:02 -!- tromp [~tromp@2a02:a210:ca3:2800:40fe:1b7b:7c1a:4d68] has joined #bitcoin-wizards 20:07 -!- tromp [~tromp@2a02:a210:ca3:2800:40fe:1b7b:7c1a:4d68] has quit [Ping timeout: 272 seconds] 20:09 -!- pinheadmz [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-wizards 20:22 -!- pinheadmz [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Quit: pinheadmz] 20:25 < jeremyrubin> All nodes can prune old blocks. It's a problem for bootstrapping, but assumeutxo helps with that 20:26 < jeremyrubin> Validating the last years of hashrate is roughly equivalent to validating all hashrate https://www.blockchain.com/en/charts/hash-rate?timespan=all 20:27 < jeremyrubin> I.e., if someone tricked you on the last year of blocks, they could probably trick you on the prior years. 20:28 < jeremyrubin> The only data you would *need* to check from old blocks to validate assumeutxo would be the unspent outputs (can ignore/filter the spent ones) 20:28 < jeremyrubin> And if you get into a txoutproof world (e.g, utreexo), then nodes won't even store your outputs, you'd have to store them to spend 20:29 < jeremyrubin> Both of the above aren't even soft forks, they are p2p changes 20:30 < jeremyrubin> Further, if you accept ZKPs into your assumption set, you could also go the route of just ZKP'ing that this chain has this much work, this UTXO set hash, and is valid 20:31 < jeremyrubin> So there would be zero data availability to catch up 20:31 < jeremyrubin> So when I claim that there's not really such a thing as on chain data availability, I'm pretty sure we shouldn't be encouraging people to expect that some other blockchain user will forward them this info. 20:34 -!- tromp [~tromp@2a02:a210:ca3:2800:53b:ea24:4bd9:9885] has joined #bitcoin-wizards 20:36 < jeremyrubin> If you want data availability, you need to have your own redundant solution. 20:36 -!- tromp_ [~tromp@2a02:a210:ca3:2800:3c74:b645:a65a:377d] has joined #bitcoin-wizards 20:37 < jeremyrubin> This is also largely true for Ethereum -- but it's harder on bandwidth given the EVM's design to pull this off 20:38 < jeremyrubin> But still, there are certainly contracts which use merkle trees on ethereum for compact lookups. And any such contract has a data availability issue 20:38 -!- tromp [~tromp@2a02:a210:ca3:2800:53b:ea24:4bd9:9885] has quit [Ping timeout: 272 seconds] 20:41 -!- tromp_ [~tromp@2a02:a210:ca3:2800:3c74:b645:a65a:377d] has quit [Ping timeout: 272 seconds] 20:43 -!- pinheadmz [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-wizards 20:48 < asukan> I see what you mean, thanks for the explaination. 20:52 < asukan> If you introduce ZKP to compress the history then there's no DA on layer 1 anymore. Without the ZKP assumption, layer 1 still provides a meaningful data availability window even if all users prune old blocks > X days, and that window is enough for protocols like ZK rollup. 20:59 < jeremyrubin> That's fair. I'm interested in knowing what the window of availability required is and if something outside consensus is sufficient 20:59 < jeremyrubin> Data consistency isn't required, right? Just *availability* 21:01 < jeremyrubin> E.g., would it be available enough to just use AWS S3 if you're just worried about a day of availability? 21:03 < jeremyrubin> Or if there's some sort of issue with using a provider, what about issuing a transaction into the Bitcoin mempool with expected acceptance of the time period (e.g., bid the median fee). 21:03 < jeremyrubin> Theoretically, the mempool is ~more available than older confirmed blocks, but less consistent. 21:04 < jeremyrubin> If you observe the transaction being low to the bottom of the mempool, you can reissue one paying higher fee 21:05 < jeremyrubin> This is cheaper than actually getting confirmed as you only pay if you get confirmed before your next state update txn 21:05 < jeremyrubin> Although IIRC RBF requires higher absolute fee and higher feerate, 21:15 < luke-jr> for ZK bootstrap to work, it also needs to be mandatory 21:16 < luke-jr> otherwise miners could make a chain and ZK proofs for it, but never provide the full blocks to non-ZK nodes 21:18 < jeremyrubin> that's kind of my point 21:19 < jeremyrubin> It *can* be mandatory 21:19 < jeremyrubin> so you can't rely on avail of old blocks 21:24 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards 21:27 < asukan> To withdraw a user needs to provide a merkle proof of his account balance, which can be re-constructed from on-chain data. A longer window would allow users to get online more infrequently, so it's more of a usability thing. 21:32 < asukan> I think consensus is needed because rebuilding the state requires a consistent view of transaction order. 21:56 -!- tromp [~tromp@2a02:a210:ca3:2800:d72:8805:17a8:ef43] has joined #bitcoin-wizards 21:56 < jeremyrubin> consensus != consistency 21:57 < jeremyrubin> if a UTXO exists, and I have a preimage i must know to spend it, and I ask Alice and she says X and I ask Bob and he says Y, I just see which one was correct 21:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 258 seconds] 21:58 < jeremyrubin> X could be saying "H(x), x is preimage" 21:58 < jeremyrubin> Y could be "Don't know H(X)'s preimage" 22:00 -!- bayashi [~bayashi@139.28.218.198] has quit [] 22:01 -!- tromp [~tromp@2a02:a210:ca3:2800:d72:8805:17a8:ef43] has quit [Ping timeout: 272 seconds] 22:06 < jeremyrubin> But just that I got some correct answer means consistency 22:07 < jeremyrubin> * availability 22:07 < jeremyrubin> Bitcoin itself is kind of like this 22:07 < jeremyrubin> Your peer could say that they don't have any blocks past a certain date 22:07 < jeremyrubin> Or claim the difficulty went down and here's a low-work chain 22:08 < jeremyrubin> But you *eventually* get a decent answer, which you can check 22:08 < jeremyrubin> But there's no point in making the way you get an answer in Bitcoin consensus the same for getting spending conditions for your txn 22:08 < jeremyrubin> In fact there are privacy reasons not to do that 22:18 -!- NilsHitze [~NilsHitze@104.254.90.235] has joined #bitcoin-wizards 22:25 -!- tromp [~tromp@2a02:a210:ca3:2800:71f0:ee99:694:c906] has joined #bitcoin-wizards 22:27 -!- shush [~pawn@2605:e000:1c02:c564:edaf:922f:ff7c:56ad] has joined #bitcoin-wizards 22:30 -!- tromp [~tromp@2a02:a210:ca3:2800:71f0:ee99:694:c906] has quit [Ping timeout: 272 seconds] 22:31 -!- pinheadmz [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Quit: pinheadmz] 22:38 -!- shush [~pawn@2605:e000:1c02:c564:edaf:922f:ff7c:56ad] has quit [Remote host closed the connection] 22:38 -!- shush [~pawn@2605:e000:1c02:c564:edaf:922f:ff7c:56ad] has joined #bitcoin-wizards 23:02 -!- francisco___ [uid418144@gateway/web/irccloud.com/x-evfawdohgdgmmvek] has quit [Quit: Connection closed for inactivity] 23:06 -!- shush [~pawn@2605:e000:1c02:c564:edaf:922f:ff7c:56ad] has quit [Remote host closed the connection] 23:20 -!- jungly [~jungly@host237-31-dynamic.249-95-r.retail.telecomitalia.it] has joined #bitcoin-wizards 23:23 -!- jimmysong [~jimmysong@209.194.241.15] has quit [Ping timeout: 255 seconds] 23:33 -!- rh0nj [~rh0nj@88.99.167.175] has quit [Remote host closed the connection] 23:54 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards 23:59 -!- tromp [~tromp@2a02:a210:ca3:2800:71f0:ee99:694:c906] has joined #bitcoin-wizards --- Log closed Sat Feb 22 00:00:00 2020