| --- Log opened Mon Feb 08 00:00:27 2016 | ||
| -!- roidster [~chatzilla@97-90-24-187.dhcp.mtpk.ca.charter.com] has quit [Quit: ChatZilla 0.9.92 [SeaMonkey 2.39/20151103191810]] | 00:04 | |
| -!- adam3us [~Adium@unaffiliated/adam3us] has joined #bitcoin-wizards | 00:07 | |
| -!- LeMiner [LeMiner@unaffiliated/leminer] has quit [Ping timeout: 246 seconds] | 00:09 | |
| -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards | 00:12 | |
| -!- jcluck [~cluckj@pool-108-16-231-242.phlapa.fios.verizon.net] has joined #bitcoin-wizards | 00:17 | |
| -!- adam3us [~Adium@unaffiliated/adam3us] has quit [Quit: Leaving.] | 00:18 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 00:20 | |
| -!- cluckj [~cluckj@pool-108-16-231-242.phlapa.fios.verizon.net] has quit [Ping timeout: 256 seconds] | 00:20 | |
| -!- cluckj [~cluckj@pool-108-16-231-242.phlapa.fios.verizon.net] has joined #bitcoin-wizards | 00:21 | |
| -!- Burrito [~Burrito@unaffiliated/burrito] has joined #bitcoin-wizards | 00:21 | |
| -!- jcluck [~cluckj@pool-108-16-231-242.phlapa.fios.verizon.net] has quit [Ping timeout: 256 seconds] | 00:22 | |
| -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards | 00:27 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 250 seconds] | 00:29 | |
| -!- jcluck [~cluckj@pool-108-16-231-242.phlapa.fios.verizon.net] has joined #bitcoin-wizards | 00:34 | |
| -!- cluckj [~cluckj@pool-108-16-231-242.phlapa.fios.verizon.net] has quit [Ping timeout: 252 seconds] | 00:37 | |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] | 00:38 | |
| -!- cluckj [~cluckj@pool-108-16-231-242.phlapa.fios.verizon.net] has joined #bitcoin-wizards | 00:39 | |
| -!- jcluck [~cluckj@pool-108-16-231-242.phlapa.fios.verizon.net] has quit [Ping timeout: 276 seconds] | 00:39 | |
| -!- tromp_ [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards | 00:44 | |
| -!- licnep [uid4387@gateway/web/irccloud.com/x-ycmowdakklglojmh] has quit [Quit: Connection closed for inactivity] | 00:46 | |
| -!- tromp_ [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Ping timeout: 245 seconds] | 00:49 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 00:49 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 01:04 | |
| -!- andy-logbot [~bitcoin--@wpsoftware.net] has quit [Remote host closed the connection] | 01:05 | |
| -!- andy-logbot [~bitcoin--@wpsoftware.net] has joined #bitcoin-wizards | 01:05 | |
| * andy-logbot is logging | 01:05 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [] | 01:10 | |
| -!- _AlienTrooper is now known as AlienTrooper | 01:13 | |
| -!- AlienTrooper [~Alien@2a00:d880:6:543::cd46] has quit [Changing host] | 01:14 | |
| -!- AlienTrooper [~Alien@unaffiliated/alientrooper] has joined #bitcoin-wizards | 01:14 | |
| -!- sCOGSBY [~uumdbmd@173.44.48.178] has quit [Read error: Connection reset by peer] | 01:34 | |
| -!- adam3us [~Adium@unaffiliated/adam3us] has joined #bitcoin-wizards | 01:37 | |
| -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] | 01:44 | |
| -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards | 01:45 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards | 01:50 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards | 01:50 | |
| -!- moa [~kiwigb@opentransactions/dev/moa] has quit [Quit: Leaving.] | 01:52 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.] | 01:58 | |
| -!- roconnor [~roconnor@host-45-58-248-194.dyn.295.ca] has quit [Ping timeout: 256 seconds] | 02:04 | |
| -!- liead [~adlie@unaffiliated/adlai] has quit [Ping timeout: 276 seconds] | 02:12 | |
| -!- btcdrak [uid115429@gateway/web/irccloud.com/x-jxtgnfhsdegmglez] has quit [Quit: Connection closed for inactivity] | 02:16 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 272 seconds] | 02:26 | |
| -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] | 02:36 | |
| -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-wizards | 02:38 | |
| -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-wizards | 02:41 | |
| -!- wasi [~wasi@25.22.3.213.static.wline.lns.sme.cust.swisscom.ch] has joined #bitcoin-wizards | 02:42 | |
| -!- tromp_ [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards | 02:45 | |
| -!- btcdrak [uid115429@gateway/web/irccloud.com/x-zkhqjzgotldxfdsm] has joined #bitcoin-wizards | 02:48 | |
| -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt] | 02:49 | |
| -!- tromp_ [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Ping timeout: 250 seconds] | 02:49 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards | 02:55 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 02:56 | |
| -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-wizards | 03:07 | |
| -!- LeMiner [LeMiner@unaffiliated/leminer] has joined #bitcoin-wizards | 03:11 | |
| -!- ttttemp [~ttttemp@nb-10350.ethz.ch] has quit [Remote host closed the connection] | 03:20 | |
| -!- grandmaster is now known as dansmith_btc | 03:23 | |
| -!- ttttemp [~ttttemp@pc-5305.ethz.ch] has joined #bitcoin-wizards | 03:27 | |
| -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] | 03:31 | |
| -!- liead [~adlie@unaffiliated/adlai] has joined #bitcoin-wizards | 03:35 | |
| -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards | 03:40 | |
| -!- voxelot [~voxelot@2605:e000:1525:802f:bf25:cb7d:8b4d:2d09] has quit [Ping timeout: 240 seconds] | 03:52 | |
| -!- roman [~quassel@ANice-652-1-329-249.w86-193.abo.wanadoo.fr] has joined #bitcoin-wizards | 03:58 | |
| -!- Peter00 [~Peter00@garza.riseup.net] has quit [Ping timeout: 256 seconds] | 04:03 | |
| -!- roman [~quassel@ANice-652-1-329-249.w86-193.abo.wanadoo.fr] has quit [Read error: Connection reset by peer] | 04:08 | |
| -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt] | 04:27 | |
| -!- liead [~adlie@unaffiliated/adlai] has quit [Read error: Connection reset by peer] | 04:32 | |
| -!- liead [~adlie@unaffiliated/adlai] has joined #bitcoin-wizards | 04:34 | |
| -!- MoALTz [~no@78-11-180-214.static.ip.netia.com.pl] has quit [Quit: Leaving] | 04:36 | |
| -!- liead [~adlie@unaffiliated/adlai] has quit [Read error: Connection reset by peer] | 04:38 | |
| -!- liead [~adlie@unaffiliated/adlai] has joined #bitcoin-wizards | 04:39 | |
| -!- liead [~adlie@unaffiliated/adlai] has quit [Ping timeout: 240 seconds] | 04:50 | |
| -!- nuke1989 [~nuke@176.92.98.61] has joined #bitcoin-wizards | 04:53 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.] | 05:00 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards | 05:01 | |
| -!- p15x [~p15x@33.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-wizards | 05:02 | |
| -!- liead [~adlie@unaffiliated/adlai] has joined #bitcoin-wizards | 05:08 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 260 seconds] | 05:18 | |
| -!- voxelot [~voxelot@2605:e000:1525:802f:18f3:1d02:b6ff:edea] has joined #bitcoin-wizards | 05:20 | |
| -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has quit [Remote host closed the connection] | 05:33 | |
| -!- voxelot [~voxelot@2605:e000:1525:802f:18f3:1d02:b6ff:edea] has quit [Ping timeout: 250 seconds] | 05:36 | |
| -!- adam3us [~Adium@unaffiliated/adam3us] has quit [Quit: Leaving.] | 05:37 | |
| -!- jtimon [~quassel@126.31.134.37.dynamic.jazztel.es] has joined #bitcoin-wizards | 05:44 | |
| -!- tromp_ [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards | 05:44 | |
| -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 245 seconds] | 05:56 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 245 seconds] | 05:59 | |
| -!- tromp_ [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Remote host closed the connection] | 06:00 | |
| -!- iddo_ [~idddo@csm.cs.technion.ac.il] has quit [Remote host closed the connection] | 06:00 | |
| -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-wizards | 06:02 | |
| -!- p15x [~p15x@33.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 245 seconds] | 06:03 | |
| -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards | 06:08 | |
| -!- MoALTz [~no@78-11-180-214.static.ip.netia.com.pl] has joined #bitcoin-wizards | 06:08 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 06:20 | |
| -!- MoALTz [~no@78-11-180-214.static.ip.netia.com.pl] has quit [Quit: Leaving] | 06:30 | |
| -!- Giszmo [~leo@pc-139-55-215-201.cm.vtr.net] has joined #bitcoin-wizards | 06:34 | |
| -!- sparetire [~sparetire@unaffiliated/sparetire] has joined #bitcoin-wizards | 06:39 | |
| -!- yorick__ is now known as yorick | 06:43 | |
| -!- liead [~adlie@unaffiliated/adlai] has quit [Read error: Connection reset by peer] | 06:44 | |
| -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards | 06:47 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards | 06:47 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Client Quit] | 06:51 | |
| -!- roidster [~chatzilla@97-90-24-187.dhcp.mtpk.ca.charter.com] has joined #bitcoin-wizards | 07:01 | |
| -!- roidster is now known as Guest70819 | 07:02 | |
| -!- Guest70819 is now known as roidster | 07:03 | |
| -!- se3000 [~textual@38.125.163.25] has joined #bitcoin-wizards | 07:03 | |
| -!- Guest25_ [~textual@38.125.163.25] has joined #bitcoin-wizards | 07:04 | |
| -!- MoALTz [~no@78-11-180-214.static.ip.netia.com.pl] has joined #bitcoin-wizards | 07:04 | |
| -!- markus-k [~markus-k@141.91.210.210] has joined #bitcoin-wizards | 07:08 | |
| -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] | 07:13 | |
| -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards | 07:15 | |
| -!- nubbins` [~leel@unaffiliated/nubbins] has joined #bitcoin-wizards | 07:18 | |
| -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-wizards | 07:19 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 256 seconds] | 07:20 | |
| -!- NewLiberty_ [~NewLibert@2602:306:b8e0:8160:b8e2:1c9c:fe32:8ba2] has joined #bitcoin-wizards | 07:21 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 07:25 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 07:25 | |
| -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] | 07:27 | |
| -!- bityogi [~textual@208-104-143-200.brvd.dsl.dyn.comporium.net] has joined #bitcoin-wizards | 07:34 | |
| -!- fkhan [weechat@gateway/vpn/mullvad/x-tbjdntsyisiyoteo] has joined #bitcoin-wizards | 07:37 | |
| -!- markus-k [~markus-k@141.91.210.210] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 07:45 | |
| -!- tromp_ [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards | 07:45 | |
| -!- conner_ [~conner@18.111.107.174] has quit [Remote host closed the connection] | 07:47 | |
| -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-wizards | 07:48 | |
| -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit] | 07:49 | |
| -!- tromp_ [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Ping timeout: 240 seconds] | 07:50 | |
| -!- adam3us [~Adium@unaffiliated/adam3us] has joined #bitcoin-wizards | 07:52 | |
| -!- bsm117532 [~mcelrath@38.121.165.30] has joined #bitcoin-wizards | 07:58 | |
| -!- conner_ [~conner@dhcp-18-111-21-238.dyn.mit.edu] has joined #bitcoin-wizards | 08:02 | |
| -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-wizards | 08:03 | |
| -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit] | 08:04 | |
| -!- voxelot [~voxelot@remote.digitalmoneycorp.com] has joined #bitcoin-wizards | 08:07 | |
| -!- voxelot [~voxelot@remote.digitalmoneycorp.com] has quit [Changing host] | 08:10 | |
| -!- voxelot [~voxelot@unaffiliated/voxelot] has joined #bitcoin-wizards | 08:10 | |
| -!- earthris1 [~earthrise@S01065404a6902716.cg.shawcable.net] has joined #bitcoin-wizards | 08:33 | |
| -!- lnovy [~lnovy@2002:4d57:f055::1] has quit [Ping timeout: 240 seconds] | 08:34 | |
| -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has joined #bitcoin-wizards | 08:36 | |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards | 08:39 | |
| -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has quit [Ping timeout: 260 seconds] | 08:42 | |
| -!- tromp_ [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards | 08:47 | |
| -!- tromp_ [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Ping timeout: 264 seconds] | 08:52 | |
| bsm117532 | NSA declared SHA-256 "unsafe" in the face of quantum computers: https://www.deepdotweb.com/2016/02/08/nsa-switches-to-quantum-resistant-cryptography/ | 08:53 |
|---|---|---|
| zooko | wth | 08:55 |
| * zooko looks | 08:55 | |
| bsm117532 | I can understand extending the recommended key size for RSA and ECC, but why do the same for symmetric algorithms? | 08:56 |
| -!- btcdrak [uid115429@gateway/web/irccloud.com/x-zkhqjzgotldxfdsm] has quit [Quit: Connection closed for inactivity] | 08:56 | |
| zooko | That's some bullshit right there. Probably based on that Brassard, Høyer, Tapp idea that they can find hash collisions at at a cube-root cost. | 08:58 |
| zooko | Or maybe based on whatever Great Game disinfo bullshit that NSA is playing. | 08:58 |
| zooko | http://cr.yp.to/hash/collisioncost-20090823.pdf | 08:58 |
| bsm117532 | zooko: Do you have a ref for that? | 08:58 |
| -!- phiche [~Adium@193.89.191.209] has quit [Ping timeout: 240 seconds] | 09:00 | |
| zooko | perhaps not entirely unrelated: NSA decided to completely eliminate the (already leaky) Chinese Wall [*] between | 09:01 |
| zooko | their offense and defense sides. | 09:01 |
| zooko | Which is, IIUC, the opposite of what the bullshit presidential panel on "What shall we do about NSA?" recommended. | 09:01 |
| zooko | [*] Hope "Chinese Wall" is not an offensive cultural idiom. | 09:01 |
| bsm117532 | Well clearly the NSA is an adversary to basically everyone, and one shouldn't take their recommendations without independent analysis... | 09:03 |
| bsm117532 | This appears to be the original: https://www.iad.gov/iad/library/ia-guidance/ia-solutions-for-classified/algorithm-guidance/cnsa-suite-and-quantum-computing-faq.cfm | 09:05 |
| bsm117532 | Pay no attention to NSA's bad SSL cert... | 09:05 |
| zooko | lol | 09:06 |
| zooko | Hrm, now I'm wondering if we should bump up the secure hash outputs in Zcash to 384 bits just so we don't have to have this conversation or endure the penumbra of FUD. | 09:07 |
| zooko | *sigh* | 09:08 |
| bsm117532 | Hey why not sha-512? No one wants factors of 3. | 09:08 |
| zooko | We're probably going to use BLAKE2s, BTW, and the reason would be that it slows us down more to have extra bits, but that would need to be measured. | 09:10 |
| zooko | gotta reboot to try to cure audio driver bugs. :-( bbiab | 09:10 |
| -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] | 09:10 | |
| -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-wizards | 09:12 | |
| bsm117532 | BTW Congrats to the Broncos zooko! | 09:12 |
| zooko | bsm117532: ☺ | 09:13 |
| zooko | bsm117532: oh yeah, BLAKE2s doesn't even go up > 256 bit outputs. Bah. | 09:13 |
| zooko | bsm117532: I'm just going to ignore that NSA FUD for now. | 09:13 |
| zooko | I'm going to act as if I know what they're up to, and what they're up to is a giant DoS on strong and open crypto development and adoption. ;-) | 09:13 |
| zooko | Zcash can't be post-quantum-secure right now anyway for other reasons. | 09:13 |
| zooko | Well, to be clear, the confidentiality properties of Zcash could be cracked by a sufficiently enormous quantum computer, if such a thing were ever to exist. | 09:14 |
| bsm117532 | their FAQ has some interesting responses on that: They don't want to force vendors from RSA->ECC->Quantum-Resistant public key since the time scale of each transition is 20-30 years and we expect Quantum-Resistant pubkey schemes in less than 20 years. | 09:14 |
| bsm117532 | So they're skipping ECC in their recommendations... | 09:14 |
| -!- phiche [~Adium@2.71.181.243.mobile.tre.se] has joined #bitcoin-wizards | 09:15 | |
| zooko | bsm117532: thanks for mining their FAQ and handing me that nugget. | 09:15 |
| bsm117532 | Actually someone else in ##crypto found it...I just copied it here. | 09:16 |
| -!- fuc [~fuc@159.148.186.135] has joined #bitcoin-wizards | 09:18 | |
| maaku | bsm117532: reading the sha3 incremental hash paper, it strikes me that it would be interesting to build a version control system using the variable-sized data hash | 09:18 |
| bsm117532 | maaku: Can you elaborate? I'm not sure what you mean. | 09:19 |
| maaku | bsm117532: the "variable-size data" incremental hash basically breaks a piece of data into a singly-linked-list structure, where you can insert/update/delete in compact form | 09:20 |
| bsm117532 | For any onlookers, I believe we're talking about https://eprint.iacr.org/2015/1028.pdf | 09:21 |
| maaku | so you could have a cryptographic version control system like monotone, except for which you don't need the full files in order to validate/apply diffs | 09:21 |
| bsm117532 | maaku: That's exactly where I'm going...you don't have to have the full UTXO set to validate/apply diffs... | 09:21 |
| maaku | (separately I've been wanting for some time to change monotone to use bitcoin-like script signatures, which would let you do cool stuff like threshold commits) | 09:22 |
| -!- conner_ [~conner@dhcp-18-111-21-238.dyn.mit.edu] has quit [Remote host closed the connection] | 09:23 | |
| maaku | bsm117532: actually for the txout spend history it's probably better to use the non-variable form | 09:23 |
| bsm117532 | I got excited to find that paper, but admit I haven't read it yet. I'll try to say something more intelligent about it later today... | 09:23 |
| maaku | and when you spend an output you just update the prior record, marking it as spent | 09:23 |
| -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards | 09:31 | |
| maaku | Well there are plusses and minuses to each approach. | 09:32 |
| -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has joined #bitcoin-wizards | 09:39 | |
| -!- phiche [~Adium@2.71.181.243.mobile.tre.se] has quit [Quit: Leaving.] | 09:40 | |
| -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has quit [Ping timeout: 245 seconds] | 09:43 | |
| -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has quit [Ping timeout: 260 seconds] | 09:49 | |
| -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer] | 09:49 | |
| -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-wizards | 09:50 | |
| -!- phiche [~Adium@2.71.181.243.mobile.tre.se] has joined #bitcoin-wizards | 09:52 | |
| -!- phiche [~Adium@2.71.181.243.mobile.tre.se] has quit [Quit: Leaving.] | 09:57 | |
| -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Ping timeout: 245 seconds] | 09:58 | |
| -!- AusteritySucks [~Austerity@unaffiliated/austeritysucks] has quit [Ping timeout: 248 seconds] | 10:03 | |
| -!- wasi [~wasi@25.22.3.213.static.wline.lns.sme.cust.swisscom.ch] has quit [Ping timeout: 256 seconds] | 10:04 | |
| -!- chmod755 [~chmod755@unaffiliated/chmod755] has joined #bitcoin-wizards | 10:09 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Read error: Connection reset by peer] | 10:09 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards | 10:09 | |
| -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards | 10:10 | |
| -!- AusteritySucks [~Austerity@unaffiliated/austeritysucks] has joined #bitcoin-wizards | 10:15 | |
| -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-wizards | 10:19 | |
| -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] | 10:21 | |
| -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 10:27 | |
| -!- arubi_ is now known as arubi | 10:29 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 256 seconds] | 10:30 | |
| -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Quit: .] | 10:30 | |
| -!- conner_ [~conner@31-35-123.wireless.csail.mit.edu] has joined #bitcoin-wizards | 10:31 | |
| -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards | 10:32 | |
| -!- Dizzle [~Dizzle@104-6-36-162.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-wizards | 10:34 | |
| -!- Oizopower [uid19103@gateway/web/irccloud.com/x-jlsudpcdyuodxkgu] has joined #bitcoin-wizards | 10:38 | |
| -!- Tasoshi [~Tasoshi@unaffiliated/tasoshi] has quit [Read error: Connection reset by peer] | 10:49 | |
| -!- Tasoshi [~Tasoshi@unaffiliated/tasoshi] has joined #bitcoin-wizards | 10:50 | |
| -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Remote host closed the connection] | 10:55 | |
| -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-wizards | 10:56 | |
| -!- espes__ [~espes@205.185.120.132] has quit [Ping timeout: 250 seconds] | 11:08 | |
| -!- phiche [~Adium@2.71.181.243.mobile.tre.se] has joined #bitcoin-wizards | 11:11 | |
| -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Ping timeout: 256 seconds] | 11:16 | |
| bsm117532 | maaku: iSHAKE256 is intended to have a security parameter of 256 bits for a set size of 32GB, and block sizes of 1MB. If I extrapolate in my head...a Merkle tree-based set of the same size for 256-bit hashes at 32GB (so about 100M outputs) requires a proof size of log_2(32e9/256)*256=7kb. | 11:16 |
| bsm117532 | maaku: Their proof sizes are ~6.5k so size-wise it's a wash. However it appears that adding or removing an element of the set may be hundreds or thousands of times faster. | 11:17 |
| bsm117532 | Sharding using such a technique implies a pretty fundamental tradeoff of storage vs. bandwidth. A txn with input and output proofs would be ~ 7kb*(#inputs + #outputs), so higher instantaneous bandwidth, though all that data could be pruned. | 11:19 |
| -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-wizards | 11:19 | |
| -!- crowleyman [~crowleyma@185.6.187.38.pool.breezein.net] has joined #bitcoin-wizards | 11:21 | |
| bsm117532 | Hitting Visa's 2000 txn/s assuming 3.5 (in/out)puts per txn comes to about 50 Mb/s bandwidth. Of course the whole idea here is sharding, so divide that by the number of nodes and multiply by a redundancy factor. Seems reasonable... | 11:21 |
| -!- AusteritySucks [~Austerity@unaffiliated/austeritysucks] has quit [Ping timeout: 240 seconds] | 11:24 | |
| bsm117532 | With a redundancy factor of 20 (each utxo is duplicated on 20 nodes) that's 200kb/s per node. | 11:24 |
| -!- conner_ [~conner@31-35-123.wireless.csail.mit.edu] has quit [Remote host closed the connection] | 11:29 | |
| -!- AusteritySucks [~Austerity@unaffiliated/austeritysucks] has joined #bitcoin-wizards | 11:38 | |
| -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Ping timeout: 240 seconds] | 11:38 | |
| bsm117532 | This is reminding me of some analysis I did a while ago on Bloom and Cuckoo filters: Their size is O(N) in the number of elements contained in the set (after you normalize out confusion in the #keys and #bits). | 11:42 |
| bsm117532 | Perhaps it's a more fundamental result that proof of set inclusion or exclusion must scale as O(log(N)) in the set size. My dream of doing it in O(1) trades hash collision resistance as the set size gets larger. | 11:43 |
| -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Ping timeout: 256 seconds] | 11:43 | |
| -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-wizards | 11:43 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 11:46 | |
| Eliel_ | I've been thinking about N-way channels lately and am now quite interested about the idea of Ns in the thousands. It should be possible to build a structure where each participant only needs to update their signature when their own output in the channel changes. Then, if individual txouts could be broadcast and included in blocks individually, while still allowing other txouts in the transaction to stay non-final, it could poten | 11:46 |
| -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-wizards | 11:47 | |
| bsm117532 | Eliel_: you got cut off... | 11:47 |
| Eliel_ | ... Then, if individual txouts could be broadcast and included in blocks individually, while still allowing other txouts in the transaction to stay non-final, it could potentially solve the scaling issue entirely. | 11:47 |
| -!- adam3us [~Adium@unaffiliated/adam3us] has quit [Quit: Leaving.] | 11:48 | |
| bsm117532 | Can you define a "N-way channel"? Are you talking about payment channels? | 11:48 |
| Eliel_ | bsm117532: yes, a payment channel with more than 2 participants. | 11:49 |
| -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 276 seconds] | 11:49 | |
| Eliel_ | with a mechanism for allowing an individual to leave the channel and take their coins out of it without forcing the entire channel to close. | 11:50 |
| bsm117532 | Well AFAIK a cooperative close of a channel can happen immediately. So it comes down to: can a set of locked UTXO's found, and the correct signatories, to close a subset of the channels. No? | 11:51 |
| -!- conner_ [~conner@dhcp-18-111-21-238.dyn.mit.edu] has joined #bitcoin-wizards | 11:51 | |
| Eliel_ | bsm117532: well, currently N-way channels come with the trouble of needing all participants to be online for anything at all to happen and you can't really allow the entire channel to close when just one participant wants out. The structure becomes useless. | 11:53 |
| Eliel_ | (not to mention spammy) | 11:53 |
| Eliel_ | for small Ns of parties that trust each other to not close it lightly, N-way channels would probably be usable even now, but it's rather limited. | 11:55 |
| -!- Peter00 [~Peter00@garza.riseup.net] has joined #bitcoin-wizards | 11:58 | |
| -!- crowleyman [~crowleyma@185.6.187.38.pool.breezein.net] has quit [Quit: Textual IRC Client: www.textualapp.com] | 11:59 | |
| -!- e4xit [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has joined #bitcoin-wizards | 12:02 | |
| -!- jposner_ [~jposner@172.98.67.11] has joined #bitcoin-wizards | 12:03 | |
| maaku | bsm117532: right, I suspect there's a fundamental reason why those proof sizes corrolate | 12:04 |
| maaku | bsm117532: however note that the incremental hash output doesn't have to be transmitted on wire! | 12:06 |
| maaku | that's where the real savings come from | 12:06 |
| maaku | If I understand it correctly, I should be able to just give you the unspent outputs and the height+position at which they were included (to construct the ID), and that is sufficient to verify they are unspent | 12:08 |
| -!- conner_ [~conner@dhcp-18-111-21-238.dyn.mit.edu] has quit [Ping timeout: 250 seconds] | 12:09 | |
| maaku | So that means a block would need to relay with the nAmount+scriptPubKey for each input it spends, and the receiver can fully validate while keeping only 330 bytes of intermediate state | 12:10 |
| maaku | no merkle trees required | 12:10 |
| maaku | that's pretty magic | 12:10 |
| -!- shesek [~shesek@bzq-84-110-211-141.cablep.bezeqint.net] has quit [Ping timeout: 240 seconds] | 12:11 | |
| maaku | Eliel_: you failed to provide justification for N-way channels in the first place | 12:13 |
| maaku | why are they interesting? | 12:13 |
| -!- NewLiberty_ [~NewLibert@2602:306:b8e0:8160:b8e2:1c9c:fe32:8ba2] has quit [Ping timeout: 260 seconds] | 12:17 | |
| -!- shesek [~shesek@bzq-84-110-211-141.red.bezeqint.net] has joined #bitcoin-wizards | 12:17 | |
| Eliel_ | maaku: an N-way channel can function as a 2-way channel between any 2 of the N participants. It could improve the efficiency of routing networks like LN a lot. | 12:17 |
| maaku | Eliel_: when you work out the number of messages required for N-way channel negotiation, and frequency of failure, I suspect it will come out looking the same as a graph of 2-way channels | 12:18 |
| Eliel_ | maaku: yes, that's the problem with them currently. | 12:18 |
| -!- cfields [~quassel@unaffiliated/cfields] has quit [Ping timeout: 252 seconds] | 12:19 | |
| -!- cfields [~quassel@unaffiliated/cfields] has joined #bitcoin-wizards | 12:19 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards | 12:20 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.] | 12:21 | |
| Eliel_ | maaku: I don't think those limitations are inherent though. | 12:21 |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards | 12:24 | |
| Eliel_ | The hard part is that making them clearly superior would require coming up with a composable structure that allowed any 2 participants to modify their own outputs without requiring everyone else from the channel to be available immediately to confirm the change. | 12:25 |
| Eliel_ | However, that breaks the ability for anyone to close the channel at will, so it also needs a mechanism that allows an individual participant to exit the channel without closing it for anyone else. | 12:26 |
| -!- rustyn_ [~rustyn@unaffiliated/rustyn] has joined #bitcoin-wizards | 12:32 | |
| -!- rustyn [~rustyn@unaffiliated/rustyn] has quit [Disconnected by services] | 12:32 | |
| -!- rustyn_ is now known as rustyn | 12:32 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.] | 12:34 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards | 12:35 | |
| -!- LeMiner [LeMiner@unaffiliated/leminer] has quit [Read error: Connection reset by peer] | 12:36 | |
| -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt] | 12:36 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 245 seconds] | 12:38 | |
| -!- conner_ [~conner@18.111.55.222] has joined #bitcoin-wizards | 12:44 | |
| -!- LeMiner [LeMiner@unaffiliated/leminer] has joined #bitcoin-wizards | 12:44 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 264 seconds] | 12:46 | |
| -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-wizards | 12:51 | |
| -!- hazirafel [~hazirafel@213.8.204.43] has joined #bitcoin-wizards | 12:54 | |
| -!- btcdrak [uid115429@gateway/web/irccloud.com/x-xlmhricsrkukefwb] has joined #bitcoin-wizards | 12:57 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards | 12:58 | |
| -!- Dizzle [~Dizzle@104-6-36-162.lightspeed.austtx.sbcglobal.net] has quit [Quit: Leaving...] | 13:00 | |
| -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-wizards | 13:03 | |
| -!- mengine [~mengine@251.92-221-142.customer.lyse.net] has quit [Remote host closed the connection] | 13:04 | |
| bsm117532 | maaku: I don't understand your argument, and I think it's because you're assuming you have the full UTXO set while I'm assuming I have only a fraction. Therefore I need to retrieve a proof from my peers for each input and output that lies outside the range of TXID's I'm holding from the UTXO set. | 13:08 |
| -!- adam3us [~Adium@unaffiliated/adam3us] has joined #bitcoin-wizards | 13:08 | |
| bsm117532 | maaku: This also implies that a miner could mine while holding *none* of the UTXO set, if all txn's had full proofs attached. One could separate compensation for storing UTXO state and mining... | 13:08 |
| -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Ping timeout: 245 seconds] | 13:11 | |
| -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards | 13:14 | |
| -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Quit: Leaving] | 13:16 | |
| -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has joined #bitcoin-wizards | 13:17 | |
| -!- nabu [~nabu@179.43.169.226] has quit [Ping timeout: 248 seconds] | 13:21 | |
| -!- nabu [~nabu@gateway/vpn/privateinternetaccess/nabu] has joined #bitcoin-wizards | 13:22 | |
| -!- wasi [~wasi@pub082136074119.dh-hfc.datazug.ch] has joined #bitcoin-wizards | 13:25 | |
| -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-wizards | 13:25 | |
| dgenr8 | bsm117532: why just the UTXO set? Suppose you hold a txid range for everything back to genesis, so you're a guy who can prove spentness for that range | 13:26 |
| bsm117532 | dgenr8: UTXO (sub-)set is exactly txid range plus vout information. | 13:27 |
| dgenr8 | so just semantics? you include something that was spent years ago? | 13:28 |
| -!- conner_ [~conner@18.111.55.222] has quit [Remote host closed the connection] | 13:28 | |
| -!- conner_ [~conner@18.111.55.222] has joined #bitcoin-wizards | 13:29 | |
| -!- AusteritySucks [~Austerity@unaffiliated/austeritysucks] has quit [Ping timeout: 276 seconds] | 13:30 | |
| dgenr8 | nodes of this type would have SPV security. which should be fine, if they are serving SPV clients. | 13:35 |
| dgenr8 | With a sufficiently narrow slice, not much distinguishes such nodes from SPV wallets. Each would register for a small set of txid stems. | 13:35 |
| -!- chmod755 [~chmod755@unaffiliated/chmod755] has quit [Quit: Ex-Chat] | 13:35 | |
| -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Ping timeout: 240 seconds] | 13:35 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 13:42 | |
| -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-wizards | 13:44 | |
| -!- AusteritySucks [~Austerity@unaffiliated/austeritysucks] has joined #bitcoin-wizards | 13:47 | |
| teslax | oh! the onboard HD4600 seems to be dead to. hm. strange. very strange. | 13:49 |
| teslax | vodka. NOW! | 13:50 |
| -!- teslax [~teslax@80-110-44-54.static.surfer.at] has left #bitcoin-wizards [] | 13:52 | |
| fluffypony | wut | 13:53 |
| -!- Oizopower [uid19103@gateway/web/irccloud.com/x-jlsudpcdyuodxkgu] has quit [Quit: Connection closed for inactivity] | 13:56 | |
| bsm117532 | dgenr8: This is better than (current) SPV security because of the UTXO proofs. I'm not verifying backwards n-blocks-deep, I'm verifying that my UTXO's are unspent at a particular height. | 13:57 |
| bsm117532 | SPV security is admittedly something I need to think more about... | 13:57 |
| -!- kelly [c0373725@gateway/web/freenode/ip.192.55.55.37] has joined #bitcoin-wizards | 14:03 | |
| bsm117532 | Taek: Does Sia or Storj or any other data-storage project compensate holders of the data? How do you prove that they hold it and prevent a MITM from claiming they held it, after the storage-holder provides it? | 14:07 |
| -!- moa [~kiwigb@opentransactions/dev/moa] has quit [Ping timeout: 252 seconds] | 14:08 | |
| -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt] | 14:08 | |
| -!- AusteritySucks [~Austerity@unaffiliated/austeritysucks] has quit [Ping timeout: 240 seconds] | 14:09 | |
| -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has quit [Ping timeout: 248 seconds] | 14:10 | |
| maaku | bsm117532: I'm not sure what use case you are imagining | 14:13 |
| maaku | bsm117532: the one I'm describing above is stateless mining | 14:13 |
| maaku | and/or stateless transaction validation for relay | 14:13 |
| bsm117532 | maaku: I'm trying to shard the blockchain, so you don't have to hold the entire UTXO set. | 14:13 |
| -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has joined #bitcoin-wizards | 14:14 | |
| maaku | bsm117532: with this scheme you don't have to hold *any* of the utxoset... | 14:14 |
| maaku | that's what I mean by stateless | 14:15 |
| bsm117532 | maaku: correct. | 14:15 |
| bsm117532 | I think we're using different words to describe functionally the same thing... | 14:15 |
| maaku | bsm117532: I'm confused as to why you need to "retrieve a proof from my peers for each input and output" | 14:16 |
| maaku | bsm117532: In principle the only data you need is 32 bytes per input spent in the block | 14:17 |
| bsm117532 | maaku: I want to attach a proof to the txn that each input is unspent at a particular block height. Once I have that and if I know the UTXO set Merkle root, I know the txn is valid, without having any of the blockchain. | 14:19 |
| bsm117532 | maaku: How do you get down to 32 bytes? | 14:20 |
| -!- AusteritySucks [~Austerity@unaffiliated/austeritysucks] has joined #bitcoin-wizards | 14:21 | |
| -!- murch [~murch@p4FE38FB9.dip0.t-ipconnect.de] has joined #bitcoin-wizards | 14:23 | |
| -!- kelly [c0373725@gateway/web/freenode/ip.192.55.55.37] has quit [Ping timeout: 252 seconds] | 14:30 | |
| -!- kelly [86868b46@gateway/web/freenode/ip.134.134.139.70] has joined #bitcoin-wizards | 14:31 | |
| dgenr8 | bsm117532: codeshark is also very concerned about incentivizing nodes. maybe you just turn SPV wallets into nodes by registering for a few extra txid stems. that helps privacy too | 14:34 |
| -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 14:41 | |
| -!- conner_ [~conner@18.111.55.222] has quit [Remote host closed the connection] | 14:41 | |
| dgenr8 | fullnodes backstop the whole thing. they can serve any proof, but you'd hope that there were dozens of other live sources so it wasn't necessary to ask | 14:44 |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 276 seconds] | 14:44 | |
| -!- tromp_ [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards | 14:47 | |
| amiller | i think it's a problem that there is no explicit incentive for being a full node | 14:47 |
| amiller | even if there were a broken incentive scheme | 14:47 |
| amiller | it would at least make it clear that it's an economic decision | 14:47 |
| amiller | actually i'm not sure hwether that's good or bad... if the main reason people run full nodes today really is osmething like altruism, then maybe a buggy incentive scheme would make them go away and fail to produce anything better | 14:47 |
| amiller | that's i think the main reason why Tor has been reluctant to adopt any payment scheme for relays | 14:48 |
| -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards | 14:48 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 245 seconds] | 14:49 | |
| amiller | on the other hand, i think this is the main reason that people apply game theory to the miners but not at all for the full nodes | 14:49 |
| -!- Guyver2_ is now known as Guyver2 | 14:49 | |
| CodeShark | We should probably stop thinking in terms of full node = validator and instead think full node = prover | 14:50 |
| CodeShark | Full nodes should be optimized for serving short proofs | 14:51 |
| dgenr8 | an idea was floated to stick the p2p protocol behind 21.co pay wrapper ... down the rabbit hole | 14:51 |
| amiller | i like the full node = prover idea | 14:51 |
| -!- tromp_ [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Ping timeout: 272 seconds] | 14:52 | |
| maaku | bsm117532: I need to understand the cryptography of iSHAKE to continue this conversation further | 14:52 |
| maaku | but it is my understanding that you don't need the per-input proofs | 14:53 |
| maaku | I could be wrong on that though | 14:53 |
| maaku | CodeShark: we shouldn't need to rely on external proofs... | 14:53 |
| CodeShark | Validation cannot be directly incentivized whereas proofs can | 14:54 |
| maaku | CodeShark: missing the point. we should design protocols that don't require central proof repositories | 14:55 |
| dgenr8 | suppose when I click the "create address" button and get 1nfeFE97fIW..., my wallet begins downloading all historical txes starting with 1nfeF, with input branches and spend branches, and registers as a prover / interested party for this stem | 14:55 |
| CodeShark | maaku, why must they be central? | 14:55 |
| maaku | CodeShark: if they were truly decentralized you'd be creating your own proofs and not need to ask anyone else | 14:56 |
| maaku | there'd be no need to incentivise proof generation, because there'd be no demand for third parties to generate proofs | 14:57 |
| CodeShark | but the computational cost of proving is generally greater than the computational cost of verifying | 14:57 |
| CodeShark | the network is heterogenous | 14:57 |
| maaku | i suspect we are talking about different things | 14:58 |
| maaku | :shrug: | 14:58 |
| CodeShark | we start with proof of work - miners create proofs that are expensive to create but cheap to verify. Then we add state transitions and proofs of valid transitions | 15:01 |
| CodeShark | then by induction if block n is valid and transitions are valid, then block n + k is valid | 15:03 |
| CodeShark | Currently the proofs of valid transitions are too big | 15:04 |
| -!- kelly [86868b46@gateway/web/freenode/ip.134.134.139.70] has quit [Ping timeout: 252 seconds] | 15:09 | |
| CodeShark | to prevent nodes from paracetizing full prover nodes we can require micropayments | 15:12 |
| CodeShark | *parasetizing | 15:12 |
| -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-wizards | 15:13 | |
| -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards | 15:13 | |
| CodeShark | You can still download the entire history from block 0 and not require short proofs | 15:14 |
| -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit] | 15:14 | |
| -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-wizards | 15:16 | |
| -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit] | 15:16 | |
| CodeShark | Anyhow, point is paying for proofs can be made incentives compatible whereas there's really no way to reward validation that's directly incentives compatible | 15:16 |
| CodeShark | You get a tragedy of the commons situation | 15:17 |
| maaku | yeah i see that you are saying "we should make it so people can get paid to serve proofs because not everyone can run a full node" | 15:18 |
| CodeShark | Yep | 15:19 |
| maaku | and I was saying "we should redesign protocols so you don't have to be a full node to build/maintain your own proofs" | 15:19 |
| -!- phiche [~Adium@2.71.181.243.mobile.tre.se] has quit [Quit: Leaving.] | 15:19 | |
| maaku | (this is -wizards) | 15:19 |
| CodeShark | Let's throw out the "full node" concept entirely in that case :) | 15:20 |
| maaku | right | 15:20 |
| dgenr8 | you could pay for a proof that an input is valid, and pay extra for the proof that it is spent | 15:21 |
| -!- wasi [~wasi@pub082136074119.dh-hfc.datazug.ch] has quit [Ping timeout: 248 seconds] | 15:22 | |
| -!- Emcy [~MC@unaffiliated/mc1984] has quit [Ping timeout: 256 seconds] | 15:23 | |
| bsm117532 | FWIW I'm thinking a totally decentralized, redundant "proof repository" which is identical to holding a fraction of the UTXO space. | 15:29 |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] | 15:29 | |
| bsm117532 | e.g. I cover txids 0x0a.... to 0x0b.... and will respond with proofs of inclusion or exclusion for txids in that range. | 15:29 |
| maaku | bsm117532: what would a 'proof of inclusion' (or exclusion) look like using iSHAKE128? | 15:30 |
| -!- Emcy [~MC@unaffiliated/mc1984] has joined #bitcoin-wizards | 15:35 | |
| -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has quit [Remote host closed the connection] | 15:37 | |
| -!- wasi [~wasi@25.22.3.213.static.wline.lns.sme.cust.swisscom.ch] has joined #bitcoin-wizards | 15:39 | |
| -!- veleiro [~veleiro@fsf/member/veleiro] has quit [Ping timeout: 276 seconds] | 15:40 | |
| -!- veleiro [~veleiro@fsf/member/veleiro] has joined #bitcoin-wizards | 15:40 | |
| -!- HostFat [~HostFat@2-235-224-2.ip230.fastwebnet.it] has joined #bitcoin-wizards | 15:41 | |
| -!- adnn [adnn@gateway/vpn/mullvad/x-rrwhoflrihjxclbr] has joined #bitcoin-wizards | 15:42 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] | 15:52 | |
| -!- veleiro [~veleiro@fsf/member/veleiro] has quit [Ping timeout: 272 seconds] | 15:54 | |
| -!- belcher [~user@unaffiliated/belcher] has quit [Read error: Connection reset by peer] | 16:05 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.] | 16:06 | |
| -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-wizards | 16:06 | |
| stevenroose | I have to go in a sec, but I'm wondering about this: Is it possible to create a transaction that spends an input you own, specifies an output for only a part of the money and allows whoever you pass the transaction to to add another output and broadcast it? | 16:09 |
| stevenroose | something like sighash_nooutput | 16:09 |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds] | 16:11 | |
| -!- veleiro [~veleiro@fsf/member/veleiro] has joined #bitcoin-wizards | 16:11 | |
| maaku | stevenroose: in a limited way with SIGHASH_SINGLE | 16:11 |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 16:12 | |
| maaku | stevenroose: better ways to accomplish the same would be to have a generalized signing mode where you explicitly indicate which outputs and inputs are being included | 16:12 |
| maaku | or more wizardly, something like one-way aggregate signatures | 16:12 |
| -!- Jeremy_Rand_2 [~user@ip68-97-38-24.ok.ok.cox.net] has quit [Ping timeout: 260 seconds] | 16:16 | |
| stevenroose | maaku, like what? | 16:17 |
| maaku | https://bitcointalk.org/index.php?topic=290971.0 | 16:17 |
| stevenroose | Wiki says about sighash single "Think of this as "sign one of the outputs-- I don't care where the other outputs go". | 16:18 |
| stevenroose | " | 16:18 |
| stevenroose | Seems like the trick? However it seems to become more complicated when multiple inputs are used | 16:18 |
| maaku | stevenroose: sighash_single means your signature covers *only* the output at the same corresponding index | 16:19 |
| maaku | strictly speaking that is exactly what you asked for | 16:19 |
| maaku | (this is what lighthouse uses) | 16:20 |
| maaku | but in real life you often care about 2+ outputs | 16:20 |
| CodeShark | It's so ugly to select output by position...would be a lot nicer to have a way of specifying the set over which you're signing and use a canonical sorting for inputs/outputs :) | 16:21 |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards | 16:22 | |
| maaku | i'm not sure the canonical ordering is required... | 16:22 |
| CodeShark | not required but still nice | 16:22 |
| CodeShark | removes a symmetry | 16:23 |
| CodeShark | Allows more compact representation and improves privacy | 16:24 |
| CodeShark | and makes the representation unique | 16:25 |
| stevenroose | The reason I was thinking about this was for outsourcing tx broadcasting for timelocked contracts for lightning | 16:34 |
| stevenroose | I imagine some kind of sub-network where users can broadcast timelocked transactions by leaving a small part of the output open for the broadcaster to spend | 16:35 |
| stevenroose | So that they can safely go offline | 16:35 |
| stevenroose | So yes, a more generic way should be nice, since there will probably be more inputs and outputs involved | 16:36 |
| wasi | a fix sorting mechanism for inputs and outputs is required anyway in order to eliminate transaction malleability, or not? | 16:40 |
| -!- Jeremy_Rand_2 [~user@172.58.104.114] has joined #bitcoin-wizards | 16:41 | |
| -!- Peter00 [~Peter00@garza.riseup.net] has quit [Quit: Peter00] | 16:46 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 272 seconds] | 16:50 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 16:52 | |
| -!- ieephm [~ieeehmm@cpe-172-90-241-198.socal.res.rr.com] has joined #bitcoin-wizards | 16:53 | |
| -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Quit: Leaving] | 16:53 | |
| -!- ieephmm [~ieeehmm@cpe-172-90-241-198.socal.res.rr.com] has quit [Ping timeout: 256 seconds] | 16:55 | |
| -!- voxelot [~voxelot@unaffiliated/voxelot] has quit [Remote host closed the connection] | 16:58 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 250 seconds] | 17:01 | |
| -!- murch [~murch@p4FE38FB9.dip0.t-ipconnect.de] has quit [Quit: Leaving.] | 17:05 | |
| -!- jcluck [~cluckj@pool-108-16-231-242.phlapa.fios.verizon.net] has joined #bitcoin-wizards | 17:09 | |
| -!- cluckj [~cluckj@pool-108-16-231-242.phlapa.fios.verizon.net] has quit [Ping timeout: 256 seconds] | 17:11 | |
| Taek | bsm117532, bsm1175321: When the host announces themselves, they include an IP address and a public key, and burn some coins (burning not implemented yet). Then, when you connect to them, they assert it's them by signing a challenge (also not implemented yet). | 17:13 |
| Taek | The file contract specifies addresses that recieve the payment if the proof is valid. | 17:13 |
| Taek | So, it doesn't matter who submits the proof, the same person gets paid | 17:14 |
| -!- roconnor [~roconnor@host-45-58-252-112.dyn.295.ca] has joined #bitcoin-wizards | 17:25 | |
| -!- Jeremy_Rand_2 [~user@172.58.104.114] has quit [Ping timeout: 240 seconds] | 17:25 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] | 17:27 | |
| -!- tromp_ [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards | 17:29 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 17:32 | |
| -!- Jeremy_Rand_2 [~user@172.58.104.114] has joined #bitcoin-wizards | 17:33 | |
| -!- tromp_ [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Remote host closed the connection] | 17:40 | |
| -!- bityogi [~textual@208-104-143-200.brvd.dsl.dyn.comporium.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 17:48 | |
| -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 240 seconds] | 17:50 | |
| -!- HostFat [~HostFat@2-235-224-2.ip230.fastwebnet.it] has quit [Quit: Leaving] | 17:56 | |
| -!- Ylbam [uid99779@gateway/web/irccloud.com/x-nygtowczsdnvwwnk] has quit [Quit: Connection closed for inactivity] | 17:58 | |
| bsm1175321 | CodeShark: I'm wandering toward the idea that providing proof that a UTXO is unspent is an incentivize-able action, and therefore storing (some of) the blockchain/UTXO set is incentivize-able. | 18:01 |
| bsm1175321 | I'm currently stuck on the fact that the proof is a Merkle path, and can be signed to indicate compensation, but any intermediary or the receiver can strip off my signature and replace his own. How do I provide a proof that simultaneously cannot repudiate the fact that I created it? | 18:02 |
| -!- jcluck is now known as cluckj | 18:03 | |
| -!- Howdy__ [~Howdy---@testbed-users.tor-exit.calyxinstitute.org] has joined #bitcoin-wizards | 18:03 | |
| bsm1175321 | CodeShark: thus I'm heading toward an incentive model that directly incentivizes (a) fast transmission of blocks -- by measurement of siblings using braids and (b) storage of pieces of the blockchain, and (c) PoW in the usual way... | 18:05 |
| bsm1175321 | maaku: Still processing iSHAKE128 but from my reading it may not provide any advantage over a Merkle path. Thus much of the logic can be worked out using a Merkle path as an example. (It might be faster, and I would like an explicit guarantee of collision resistance as the output set grows -- by allowing the proof size to grow) | 18:08 |
| bsm1175321 | Per my conjecture earlier, I think the proof size probably must grow as log(n) -- which I would like to prove or otherwise convince myself of... | 18:08 |
| -!- tromp_ [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards | 18:09 | |
| -!- brg444 [415e49c7@gateway/web/freenode/ip.65.94.73.199] has joined #bitcoin-wizards | 18:09 | |
| bsm1175321 | Taek: So you're not using any kind of PoW there, it's kind of a PoS hybrid... This problem seems harder than I first imagined. | 18:10 |
| -!- chris___ [~chris@208.185.52.110] has joined #bitcoin-wizards | 18:11 | |
| -!- Jeremy_Rand_2 [~user@172.58.104.114] has quit [Ping timeout: 260 seconds] | 18:13 | |
| -!- chris___ is now known as glitch003 | 18:14 | |
| bsm1175321 | Taek: FWIW that puts you in the camp of counting nodes, and therefore, Byzantine Fault Tolerance, for which no more than 1/3 of nodes can be faulty/fraudulent. | 18:15 |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] | 18:16 | |
| -!- adnn_ [~adnn@cpe-158-222-198-108.nyc.res.rr.com] has joined #bitcoin-wizards | 18:18 | |
| -!- adnn [adnn@gateway/vpn/mullvad/x-rrwhoflrihjxclbr] has quit [Ping timeout: 252 seconds] | 18:22 | |
| -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving] | 18:22 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 18:23 | |
| -!- conner_ [~conner@c-98-216-48-105.hsd1.ma.comcast.net] has joined #bitcoin-wizards | 18:27 | |
| -!- bildramer [~bildramer@p5DC8ADCC.dip0.t-ipconnect.de] has quit [Ping timeout: 256 seconds] | 18:31 | |
| -!- bildramer [~bildramer@p5DC8ADCC.dip0.t-ipconnect.de] has joined #bitcoin-wizards | 18:33 | |
| -!- espes__ [~espes@205.185.120.132] has joined #bitcoin-wizards | 18:40 | |
| -!- Jeremy_Rand_2 [~user@172.58.104.114] has joined #bitcoin-wizards | 18:42 | |
| Taek | bsm1175321: no, the consensus is driven by POW. The file contract is a type of transaction, and is not used to secure consensus | 18:43 |
| -!- wallet42 [~wallet42@172.56.18.226] has joined #bitcoin-wizards | 18:43 | |
| Taek | storage hosts don't play a role in mining | 18:43 |
| bsm1175321 | Taek: There's a separate problem to be solved here: In PoW, miners commit to their own coinbase in such a way that makes it impractical for anyone else to replace their coinbase with a payout to themselves. But if storage providers get paid for storage, how do they make a similar cryptographic commitment to the results of queries? The description you provide above is effectively a PoS algorithm (in proving stora | 18:45 |
| Taek | I'm not seeing how it's a PoS algorithm? It's a system with identity. Hosts have identity and reputation, and you choose between hosts based on your own view of how likely they are to keep your data vs. how much they are charging | 18:47 |
| Taek | though, reputation is measured by each client individually. You don't trust any information others tell you about a host, you only trust what you observe | 18:47 |
| Taek | PoS to me implies that somehow people are voting on which hosts should get data, which is not the case. Each client fully controls which hosts they upload to | 18:48 |
| bsm1175321 | Ok, strike PoS. But you are in the class of literature for Byzantine Fault Tolerance. | 18:49 |
| -!- voxelot [~voxelot@2605:e000:1525:802f:18f3:1d02:b6ff:edea] has joined #bitcoin-wizards | 18:49 | |
| -!- Jeremy_Rand_2_ [~user@172.56.7.182] has joined #bitcoin-wizards | 18:50 | |
| Taek | Depends on what definition you are using. To recover data, you do require that at least some fraction of hosts are still storing the data you gave them, and are willing to upload it to you upon request | 18:50 |
| Taek | But it's not limited to 1/3 - it's related to the redundancy scheme that you use | 18:50 |
| bsm1175321 | Taek the 1/3 is related to the notion that nodes can lie. | 18:51 |
| bsm1175321 | It's not a redundancy factor. | 18:51 |
| Taek | what are the nodes able to lie about? There's no part of the protocol that relies on trusting messages from other nodes | 18:52 |
| bsm1175321 | Though I think the classic Byzantine results do not include the possibility that validity of results could be proved. | 18:52 |
| -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Read error: Connection reset by peer] | 18:52 | |
| -!- Jeremy_Rand_2 [~user@172.58.104.114] has quit [Ping timeout: 276 seconds] | 18:52 | |
| -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards | 18:53 | |
| bsm1175321 | exactly...do you know of any literature which deals with that case? It's a particular restriction on the BFT case. (FWIW I'm categorizing BFT = counting nodes) | 18:53 |
| Taek | I do think that MitM is a risk, but only if the communications aren't established correctly. But, it does seem complicated/mistake-prone | 18:53 |
| Taek | Sia doesn't count nodes? | 18:53 |
| -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.] | 18:53 | |
| bsm1175321 | Then how do you know you have the whole dataset? | 18:53 |
| Taek | it collects a set of nodes, weights them by desirability, and then chooses the most desirable | 18:53 |
| -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-wizards | 18:54 | |
| -!- hazirafel [~hazirafel@213.8.204.43] has quit [Ping timeout: 245 seconds] | 18:54 | |
| Taek | you give the data to some set of nodes of your choice, then you request data from them. In the very simple case, you give each node a full copy of the data. Then, if any of the nodes is willing to upload your data to you, you can get the data back | 18:54 |
| Taek | in that case, you only need 1/N nodes to be honest, for any size N. But as N increases so does the overhead | 18:55 |
| bsm1175321 | So Sia is not a guaranteed data storage mechanism? | 18:55 |
| Taek | no, it relies on at least some subset of nodes being willing to upload your data to you - but they are incentivized to do so | 18:55 |
| bsm1175321 | So IOW you need one node to be honest, and you can validate his result? | 18:55 |
| Taek | (because you pay them to retrieve your data) | 18:55 |
| Taek | yeah | 18:56 |
| bsm1175321 | Ok | 18:56 |
| bsm1175321 | Hmmm. | 18:56 |
| Taek | for Sia, we use M/N Reed-Solomon coding, so you actually need N nodes to be honest | 18:56 |
| Taek | *M nodes | 18:56 |
| Taek | but I do think that's a reasonable requirement | 18:56 |
| Taek | *as long as the incentives are set up correctly | 18:57 |
| bsm1175321 | Can you validate individual nodes, including the coding, or can you only validate after decoding (including possibly false participants and decoding failure)? | 18:57 |
| Taek | you can validate the nodes indiviually, including the coding. You keep the Merkle hashes of each piece | 18:57 |
| bsm1175321 | Ok | 18:57 |
| -!- glitch00_ [~chris@208.185.52.110] has joined #bitcoin-wizards | 18:57 | |
| -!- glitch003 [~chris@208.185.52.110] has quit [Read error: Connection reset by peer] | 18:57 | |
| bsm1175321 | FWIW in case you weren't following the previous conversation, I'm looking for a way to prove storage of (part of) a large UTXO set, including a signature of some kind that includes how someone should be compensated. So I guess your proof is of the "bonded validator" type. Can a recipient of data strip off the headers from a downstream storage node and claim a reward for himself? Why or why not? | 18:59 |
| -!- wallet42 [~wallet42@172.56.18.226] has quit [Read error: Connection reset by peer] | 19:02 | |
| -!- wallet42 [~wallet42@172.56.18.226] has joined #bitcoin-wizards | 19:02 | |
| -!- bityogi [~textual@208-104-143-200.brvd.dsl.dyn.comporium.net] has joined #bitcoin-wizards | 19:03 | |
| -!- conner_ [~conner@c-98-216-48-105.hsd1.ma.comcast.net] has quit [Remote host closed the connection] | 19:10 | |
| -!- sparetire [~sparetire@unaffiliated/sparetire] has quit [Quit: sparetire] | 19:13 | |
| -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has quit [Remote host closed the connection] | 19:13 | |
| -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has joined #bitcoin-wizards | 19:13 | |
| -!- glitch00_ [~chris@208.185.52.110] has quit [] | 19:15 | |
| -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 240 seconds] | 19:15 | |
| -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has quit [Remote host closed the connection] | 19:19 | |
| -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-wizards | 19:20 | |
| phantomcircuit | bsm1175321, why? | 19:20 |
| Taek | I don't know how to safely manage compensation if it's not direct. We manage compensation by saying 'if anybody proves that they have X, Alice gets paid'. Only Alice cares, therefore Alice is probably (but not necessarily) the one writing the proof. I'm not sure if there's a good way to manage compensation otherwise. | 19:22 |
| phantomcircuit | Taek, what's he talking about? | 19:23 |
| bsm1175321 | phantomcircuit: can you ask a more specific question? ;-) -- Sharding the blockchain. | 19:23 |
| phantomcircuit | bsm1175321, that can mean one of two things, sharding storage of blocks or sharding the utxo set in some way | 19:24 |
| phantomcircuit | which do you mean? | 19:24 |
| bsm1175321 | phantomcircuit: sharding utxo set. | 19:24 |
| bsm1175321 | Well, both really. | 19:24 |
| bsm1175321 | But at the moment I'm thinking about transaction validation in the case where I don't have the whole utxo set, and ignoring questions of reorgs. | 19:25 |
| phantomcircuit | bsm1175321, ok so you're either talking about a system with spv security, or a system with fraud proofs | 19:25 |
| bsm1175321 | phantomcircuit: suggestions for clear terminology welcome. | 19:26 |
| phantomcircuit | neither of which is as strong as a full node | 19:26 |
| bsm1175321 | phantomcircuit: fraud proofs. But I'm not using them for proof-of-fraud. | 19:26 |
| Taek | or a system using bft-style consensus, which is vulnerable to Sybil attacks and is usually permissioned | 19:26 |
| -!- Jeremy_Rand_2_ [~user@172.56.7.182] has quit [Ping timeout: 250 seconds] | 19:26 | |
| -!- bityogi [~textual@208-104-143-200.brvd.dsl.dyn.comporium.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 19:27 | |
| phantomcircuit | Taek, im just going to ignore systems that are trivial sybil vulnerable since well duh :) | 19:27 |
| bsm1175321 | Well -- walking the dog I was thinking of keeping two Merkle trees -- one of the UTXO set and another of validators/storage, indicating the range they are storing and a payout address. PoW then commits to both. | 19:27 |
| phantomcircuit | bsm1175321, why do you want to pay people for fraud proofs? | 19:27 |
| bsm1175321 | phantomcircuit: I'm trying to find a way to provide to you a Merkle path (indicating proof of a UTXO in the last block) and get paid for providing it. e.g. proof of storage of a fraction of the UTXO set. | 19:28 |
| bsm1175321 | phantomcircuit: To incentivize people to hold the UTXO set, once it is much larger than it is now. | 19:29 |
| -!- Jeremy_Rand_2_ [~user@172.56.6.170] has joined #bitcoin-wizards | 19:29 | |
| bsm1175321 | Also as a means to divide it up in such a way that no one entity is required to hold it all. | 19:29 |
| bsm1175321 | phantomcircuit: So, imagine attaching to a txn a proof that each of its inputs is unspent at a specific block height... | 19:29 |
| phantomcircuit | bsm1175321, i cant see how you could reasonably calculate fraud proofs for some of the aggregate functions without having the entire utxo | 19:30 |
| phantomcircuit | one of those being the inflation rules | 19:30 |
| bsm1175321 | phantomcircuit: can you elaborate? | 19:30 |
| phantomcircuit | bsm1175321, hmm actually nvm that's wrong | 19:33 |
| phantomcircuit | but then literally there would be no nodes will full security... | 19:33 |
| bsm1175321 | phantomcircuit: correct. But the system would be FAR more scalable and every node can validate correct state transitions independently. | 19:33 |
| bsm1175321 | Because the "fraud proof" gives enough info to rebalance the Merkle tree and calculate the new Merkle root after applying it. | 19:34 |
| bsm1175321 | (That's the Merkle root of all UTXO's -- bramc's Merkle Set commitment) | 19:34 |
| bsm1175321 | or something similar | 19:34 |
| phantomcircuit | bsm1175321, i guess a single individual that operated enough of the sharding servers to cover the entire range would have equivalent of fraud proof security in theory | 19:35 |
| bsm1175321 | phantomcircuit: Yes, it's quite likely that many entities would choose to cover the entire UTXO set space across multiple servers. | 19:36 |
| bsm1175321 | But depending on that is THE major factor preventing scaling of bitcoin. | 19:36 |
| phantomcircuit | in practice though how do you think real users of the system will handle it if the miner doesn't provide a portion of a block to anybody except for the spv client they intend to attack? | 19:36 |
| phantomcircuit | or even worse | 19:37 |
| bsm1175321 | phantomcircuit: You'll have to elaborate for me. What do miners have to do with this? | 19:37 |
| phantomcircuit | what if the miner creates an invalid block on purpose and then uses that to reorg the NEXT block | 19:37 |
| phantomcircuit | bsm1175321, i assume you're not thinking about a system without PoW? | 19:38 |
| bsm1175321 | phantomcircuit: Say for the sake of argument a "block" is a single transaction, including its "fraud proofs"/"UTXO set inclusion proofs". Everyone can validate that. How can a miner create an invalid block? | 19:38 |
| bsm1175321 | phantomcircuit: all PoW all the way baby. | 19:38 |
| phantomcircuit | bsm1175321, ok now lets say a miner constructs a block at height 1 which contains a double spend | 19:38 |
| phantomcircuit | however it only provides partial block fragments to the various parts of the network | 19:39 |
| bsm1175321 | That is to say, the "fraud proof" is a Merkle path from the (known) root at height N, and using said proofs I can calculate the new root at height N+1. | 19:39 |
| phantomcircuit | then it sends someone a bunch of coins which get included in block height 2 | 19:39 |
| phantomcircuit | and then the miner reveals that block 1 was invalid | 19:39 |
| phantomcircuit | well now you're screwed | 19:39 |
| bsm1175321 | phantomcircuit: A txn must include ALL fraud proofs to be valid. | 19:40 |
| bsm1175321 | Can you define "partial block fragments"? | 19:40 |
| phantomcircuit | bsm1175321, the system you're describing is one in which nobody ever sees the full block except for the miner | 19:40 |
| phantomcircuit | correct? | 19:40 |
| -!- veleiro [~veleiro@fsf/member/veleiro] has quit [Read error: Connection reset by peer] | 19:40 | |
| bsm1175321 | No one is *required* to see the full block except the miner, correct. | 19:41 |
| phantomcircuit | there's a bunch of these sharding servers which only need to see some of the transactions | 19:41 |
| phantomcircuit | hmm actually i dont think that's right | 19:41 |
| phantomcircuit | no it is | 19:41 |
| bsm1175321 | Imagine a division between sharding/storage servers and PoW miners, both of which get paid for their services. | 19:41 |
| phantomcircuit | they only need to see transactions where an input is in its shard or the transactions outputs would be in its shard | 19:42 |
| bsm1175321 | If a miner sees a txn with only partial fraud proofs, it queries servers it knows cover the relevant range of the UTXO set to obtain a fraud proof, and then mines it. | 19:42 |
| bsm1175321 | phantomcircuit: Correct, I would never see txn's that involve UTXO's outside my shard. | 19:42 |
| phantomcircuit | that means a miner can construct a block which appears valid to all users of the system until they later reveal it to be invalid | 19:42 |
| phantomcircuit | that seems like a very bad idea | 19:42 |
| bsm1175321 | How? | 19:43 |
| bsm1175321 | I'm assuming all shards/miners see the root hash, so can validate a Merkle path involving that root hash. | 19:43 |
| bsm1175321 | So, you can't construct an invalid txn or fraud proof. | 19:43 |
| phantomcircuit | bsm1175321, explain how such a system deals with a miner including two transactions in the same block and simply refusing to provide the second transaction to anybody | 19:44 |
| phantomcircuit | the fraud proof generators cannot prove to anybody else that the miner refused to produce the transaction | 19:45 |
| bsm1175321 | For the sake of simplicity I'm assuming transactions are mined individually. | 19:45 |
| phantomcircuit | all they can do is claim to not have it | 19:45 |
| phantomcircuit | bsm1175321, im thinking that's an assumption that makes the system less than practical :P | 19:45 |
| bsm1175321 | In a block, the set of transactoins, with their fraud proofs, represent a set of transitions on the root hash. One cannot compute this transition without the fraud proofs. | 19:46 |
| bsm1175321 | So, a block excluding fraud proofs would have to be invalid. | 19:46 |
| bsm1175321 | One step at a time... ;-) | 19:46 |
| phantomcircuit | bsm1175321, would have to include the fraud proofs? | 19:47 |
| phantomcircuit | wait what | 19:47 |
| bsm1175321 | Yes blocks would include fraud proofs. | 19:48 |
| phantomcircuit | the fundamental issue here is that you cannot prove fraud without all of the data | 19:48 |
| phantomcircuit | bsm1175321, that's less a fraud proof and more a proof of non-fraud | 19:48 |
| bsm1175321 | exactly, which is why I eschewed use of the term "fraud proof". It's outsourced validation, really... | 19:49 |
| -!- conner_ [~conner@dhcp-18-111-107-64.dyn.MIT.EDU] has joined #bitcoin-wizards | 19:49 | |
| bsm1175321 | Turning the idea on its head... | 19:49 |
| phantomcircuit | bsm1175321, i dont think anybody has actually constructed a system in which you can prove non-fraud completely | 19:52 |
| bsm1175321 | No, I don't think they have. But rewinding the conversation a bit, it can be done (a) by providing Merkle paths in such a way that the "path" enables a receiver of the "path" to recompute the root after removing the leaf or (b) by use of incremental hash functions (some refs I posted earlier today) which allow the same thing. | 19:54 |
| bsm1175321 | The required proof is proof of existence in a set, *and* the ability to compute the new Merkle root for that (sorted) set after removing that element. | 19:55 |
| bsm1175321 | A Merkle path is sufficient for the first, the second I'm still a bit concerned about, in the event the tree requires a large amount of rearrangement. | 19:56 |
| phantomcircuit | bsm1175321, proof of inclusion in the utxo set is necessary but not sufficient | 19:57 |
| phantomcircuit | to prove that a transaction is valid you must prove inclusion in the utxo set and prove that all blocks from that point onwards are valid | 19:57 |
| phantomcircuit | the reason for this is the attack i described above | 19:57 |
| phantomcircuit | a miner can simply refuse to produce part of a block and then reverse many many blocks without direct loss | 19:58 |
| phantomcircuit | since nominally they would sell the coins from the reward long before revealing that the block is in fact invalid | 19:58 |
| phantomcircuit | and worse still conducting such an attack would require only a tiny amount of hashing power | 19:59 |
| bsm1175321 | phantomcircuit: I don't fully understand your proposed attack. But... | 19:59 |
| phantomcircuit | so little that the arguments around miners not "sabotaging their business" are even more ridiculous than they are today | 19:59 |
| phantomcircuit | bsm1175321, you cannot prove that a block is valid without having the entire blocks contents, it's simply impossible on it's face | 19:59 |
| bsm1175321 | phantomcircuit: My perspective on that is that one need not prove "all blocks from that point onward". Rather, one can create a valid block some time in the past, and it defines a fork in the usual way, and one must evaluate whether it has more work than the chain tip, in the usual way. | 19:59 |
| bsm1175321 | phantomcircuit: I'm assuming I have the entire block, including all its fraud proofs. | 20:00 |
| phantomcircuit | and im not aware of anyway for a block to be moved from a valid to partially valid state without serious repercussions to the incentives structure | 20:00 |
| phantomcircuit | bsm1175321, if you're assuming you have the entire block then why bother with sharding? the primary cost is bandwidth and will likely remain that way for years to come | 20:01 |
| phantomcircuit | :P | 20:01 |
| -!- NewLiberty_ [~NewLibert@2602:304:cff8:1580:bd7d:1c91:2a8d:9bd7] has joined #bitcoin-wizards | 20:02 | |
| bsm1175321 | phantomcircuit: Let's take a step back and simplify. I'm trying to noodle out a very hypothetical currency in which: (a) the UTXO set is held by many parties, fractionally. (b) Those parties provide proofs of inclusion in the UTXO set, and therefore proof of validity of a transaction. (c) transactions are appended with proofs of inclusion at a specific height. (d) Miners then mine individual transactions includ | 20:03 |
| bsm1175321 | I do see this as a path to sharding bitcoin, but one step at a time. | 20:04 |
| phantomcircuit | bsm1175321, i mean, that might work but wouldn't be very useful | 20:04 |
| bsm1175321 | phantomcircuit: why? | 20:04 |
| phantomcircuit | well first off the 1:1 block:transaction ratio would be pretty aweful pretty quickly under a scenario that has high enough volume to warrant utxo sharding | 20:05 |
| bsm1175321 | Not if you bring the target difficulty down to match. | 20:05 |
| phantomcircuit | but more so the system requires that virtually everybody sees all of the historic blocks, but then they dont attempt any serious validation | 20:05 |
| bsm1175321 | But the validation is in the txn itself! | 20:06 |
| phantomcircuit | i suspect that validating the proofs of inclusion would actually be more expensive the maintaining a local utxo database in virtually all instances | 20:06 |
| bsm1175321 | Hrm? Validating proof of inclusion is just: (root) -> branch -> branch -> ... (txid) and validating that the set of Merkle pairwise hashes results in the root (which you already knew) | 20:07 |
| bsm1175321 | s/txid/utxo/ | 20:08 |
| -!- Jeremy_Rand_2_ [~user@172.56.6.170] has quit [Ping timeout: 250 seconds] | 20:08 | |
| bsm1175321 | Let's assume leaf nodes are hash(txid, vout). | 20:08 |
| phantomcircuit | bsm1175321, utxo set inclusion check can be made to be O(1) (if we ignore realities of hard ware) | 20:08 |
| phantomcircuit | all you need is enough disk space to build a hash table | 20:08 |
| bsm1175321 | And what if you can't hold the whole hash table in RAM? | 20:08 |
| -!- r0ach [~r0ach@107-217-214-192.lightspeed.jcvlfl.sbcglobal.net] has joined #bitcoin-wizards | 20:09 | |
| bsm1175321 | Can it still be done in O(1)? | 20:09 |
| -!- wallet42 [~wallet42@172.56.18.226] has quit [Quit: Leaving.] | 20:09 | |
| phantomcircuit | bsm1175321, O(1) doesn't mean it's fast | 20:09 |
| phantomcircuit | just that it's constant time | 20:09 |
| bsm1175321 | Hehehee | 20:09 |
| phantomcircuit | and the answer is yes | 20:09 |
| phantomcircuit | it would still be O(1) average case | 20:09 |
| phantomcircuit | i mean a hash table in memory and on disk | 20:09 |
| phantomcircuit | hell you'd even just mmap the file | 20:09 |
| phantomcircuit | i think libbitcoin does this actually | 20:10 |
| bsm1175321 | So what happens when the set size is larger than a single physical disk? | 20:10 |
| bsm1175321 | And I have to reach across shards? | 20:10 |
| phantomcircuit | raid? | 20:10 |
| bsm1175321 | We're trying to build a p2p currency here, not a Google datacenter. :-P | 20:10 |
| phantomcircuit | but in all seriousness that would be like ludicrously huge | 20:10 |
| -!- jtimon [~quassel@126.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 250 seconds] | 20:10 | |
| phantomcircuit | a single utxo entry should be like 32 + 4 + 32 bytes long (assuming optimized p2sh) | 20:11 |
| phantomcircuit | could even reduce it to a single 32 byte entry | 20:11 |
| bsm1175321 | Let's just hash the shit and call it 32 bytes. | 20:12 |
| phantomcircuit | (i've been kind of tempted to do this in bitcoin except it would require a separate database mapping txid + index to scriptPubKey | 20:12 |
| bsm1175321 | phantomcircuit: I'd be very happy to hear of an algorithm that can be O(1) across shards. The description above is log(n) in space...and I'm beginning to think that O(1) is impossible. | 20:13 |
| phantomcircuit | but then the main utxo db would be much much smaller which could give a pretty nice performance improvement | 20:13 |
| phantomcircuit | bsm1175321, sure just implement the UTXO DB as a hash table | 20:13 |
| bsm1175321 | Yes, if the UTXO set was a (32 byte):(64 bit) hash map... | 20:13 |
| phantomcircuit | tada | 20:13 |
| bsm1175321 | How do you shard a hash table? | 20:14 |
| phantomcircuit | bsm1175321, no no i mean literally just 32 byte entries in a "hash table set" | 20:14 |
| bsm1175321 | and provide proof of inclusion? | 20:14 |
| bsm1175321 | The proofs are hard. Most hash tables use non-cryptographic hash functions for speed, so finding collisions is trivial. | 20:14 |
| phantomcircuit | bsm1175321, you cant build a compat proof of inclusion without a merkle tree | 20:14 |
| bsm1175321 | This may force one to worst case, which is probably log(n) | 20:14 |
| phantomcircuit | well i mean zk-SNARKS but like | 20:15 |
| phantomcircuit | lol | 20:15 |
| bsm1175321 | zooko would disagree, and I wish him the best of luck, but I'm looking for zk-FASTER. | 20:15 |
| -!- brg444 [415e49c7@gateway/web/freenode/ip.65.94.73.199] has quit [Ping timeout: 252 seconds] | 20:19 | |
| -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has joined #bitcoin-wizards | 20:20 | |
| phantomcircuit | bsm1175321, zk-SNARKS for things we cannot do otherwise seems like a not-bad idea | 20:22 |
| bsm1175321 | phantomcircuit: I'm willing to accept log(n) in the meantime, and plan on soft-forking in an O(1) zk-SNARK. ;-) | 20:23 |
| -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has quit [Ping timeout: 240 seconds] | 20:24 | |
| amiller | hooray | 20:26 |
| bsm1175321 | You think log(n) is big. Go build a zk-SNARK and come back to me... | 20:27 |
| phantomcircuit | amiller, hello | 20:27 |
| amiller | hi phantomcircuit | 20:27 |
| bsm1175321 | amiller I have a serious problem with you. I appreciate your contributions here but I have an ex-girlfriend whose father has the same first initial and last name. AND IT'S ALL YOUR FAULT. | 20:28 |
| bsm1175321 | Clearly it's nearly midnight where I am and I'm getting loopy. | 20:29 |
| petertodd | bsm1175321: ACK | 20:29 |
| amiller | terrifying | 20:30 |
| * bsm1175321 has no idea why petertodd acked him. He has an ex- too? | 20:30 | |
| petertodd | bsm1175321: "Clearly it's nearly midnight where I am and I'm getting loopy." <- ACK | 20:30 |
| bsm1175321 | The gin has NOTHING to do with it. | 20:31 |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 250 seconds] | 20:32 | |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards | 20:34 | |
| bsm1175321 | Anyway, I hope you all will be interested in discussing sharding/proof of inclusion/fraud proofs/incremental hash functions in the morning. Thanks especially maaku, Taek, phantomcircuit, I do think this direction is interesting and leads somewhere...It's been an interesting day. | 20:34 |
| * bsm1175321 marvels at being able to talk to such interesting and knowledgeable people on IRC. The 21st century is awesome... Also, IRC is very, very old. | 20:36 | |
| -!- roconnor [~roconnor@host-45-58-252-112.dyn.295.ca] has quit [Quit: Konversation terminated!] | 20:39 | |
| -!- Emcy [~MC@unaffiliated/mc1984] has quit [Ping timeout: 276 seconds] | 20:39 | |
| -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has joined #bitcoin-wizards | 20:52 | |
| -!- sCOGSBY [~uumdbmd@173.44.48.178] has joined #bitcoin-wizards | 20:56 | |
| -!- nubbins` [~leel@unaffiliated/nubbins] has quit [Quit: Quit] | 21:03 | |
| -!- nubbins` [~leel@unaffiliated/nubbins] has joined #bitcoin-wizards | 21:04 | |
| -!- Jeremy_Rand_2_ [~user@ip68-97-38-24.ok.ok.cox.net] has joined #bitcoin-wizards | 21:22 | |
| -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] | 21:36 | |
| -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-wizards | 21:38 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] | 21:38 | |
| -!- nuke1989 [~nuke@176.92.98.61] has quit [Remote host closed the connection] | 21:40 | |
| -!- tromp_ [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Remote host closed the connection] | 21:41 | |
| -!- roidster [~chatzilla@97-90-24-187.dhcp.mtpk.ca.charter.com] has quit [Ping timeout: 276 seconds] | 21:53 | |
| -!- Giszmo [~leo@pc-139-55-215-201.cm.vtr.net] has quit [Quit: Leaving.] | 21:57 | |
| -!- nubbins` [~leel@unaffiliated/nubbins] has quit [Quit: Quit] | 22:01 | |
| -!- nubbins` [~leel@unaffiliated/nubbins] has joined #bitcoin-wizards | 22:05 | |
| -!- nubbins` [~leel@unaffiliated/nubbins] has quit [Client Quit] | 22:05 | |
| -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] | 22:08 | |
| -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-wizards | 22:10 | |
| -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] | 22:30 | |
| -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-wizards | 22:32 | |
| -!- tromp_ [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards | 22:41 | |
| -!- tromp_ [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Ping timeout: 252 seconds] | 22:46 | |
| Luke-Jr | bsm1175321: lolwut | 22:54 |
| -!- Ylbam [uid99779@gateway/web/irccloud.com/x-jlzykkxpyjvehcgh] has joined #bitcoin-wizards | 22:57 | |
| phantomcircuit | Luke-Jr, he's marveling at being able to talk to me, dont be jealous | 22:58 |
| * phantomcircuit runs away | 22:58 | |
| bsm1175321 | Thank goodness you weren't here Luke-Jr. | 23:00 |
| Luke-Jr | I'm pretty sure you don't have an ex-girlfriend whose father was a Dashjr | 23:00 |
| aj | Luke-Jr: but maybe he has an ex-girlfriend whose ex-boyfriend was Dashing? that's pretty close, right? | 23:02 |
| Luke-Jr | no | 23:04 |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 23:14 | |
| -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] | 23:23 | |
| -!- AusteritySucks [~Austerity@unaffiliated/austeritysucks] has quit [Ping timeout: 248 seconds] | 23:25 | |
| -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-wizards | 23:25 | |
| -!- voxelot [~voxelot@2605:e000:1525:802f:18f3:1d02:b6ff:edea] has quit [Ping timeout: 252 seconds] | 23:35 | |
| -!- AusteritySucks [~Austerity@unaffiliated/austeritysucks] has joined #bitcoin-wizards | 23:38 | |
| -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 272 seconds] | 23:43 | |
| -!- AusteritySucks [~Austerity@unaffiliated/austeritysucks] has quit [Ping timeout: 250 seconds] | 23:48 | |
| -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] | 23:51 | |
| -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-wizards | 23:53 | |
| -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards | 23:55 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 276 seconds] | 23:56 | |
| --- Log closed Tue Feb 09 00:00:28 2016 | ||
Generated by irclog2html.py 2.15.0.dev0 by Marius Gedminas - find it at mg.pov.lt!