--- Log opened Mon Feb 08 00:00:27 2016
00:04 -!- roidster [~chatzilla@97-90-24-187.dhcp.mtpk.ca.charter.com] has quit [Quit: ChatZilla 0.9.92 [SeaMonkey 2.39/20151103191810]]
00:07 -!- adam3us [~Adium@unaffiliated/adam3us] has joined #bitcoin-wizards
00:09 -!- LeMiner [LeMiner@unaffiliated/leminer] has quit [Ping timeout: 246 seconds]
00:12 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards
00:17 -!- jcluck [~cluckj@pool-108-16-231-242.phlapa.fios.verizon.net] has joined #bitcoin-wizards
00:18 -!- adam3us [~Adium@unaffiliated/adam3us] has quit [Quit: Leaving.]
00:20 -!- 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:21 -!- 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:22 -!- jcluck [~cluckj@pool-108-16-231-242.phlapa.fios.verizon.net] has quit [Ping timeout: 256 seconds]
00:27 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
00:29 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 250 seconds]
00:34 -!- jcluck [~cluckj@pool-108-16-231-242.phlapa.fios.verizon.net] has joined #bitcoin-wizards
00:37 -!- cluckj [~cluckj@pool-108-16-231-242.phlapa.fios.verizon.net] has quit [Ping timeout: 252 seconds]
00:38 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving]
00:39 -!- 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:44 -!- tromp_ [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards
00:46 -!- licnep [uid4387@gateway/web/irccloud.com/x-ycmowdakklglojmh] has quit [Quit: Connection closed for inactivity]
00:49 -!- tromp_ [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Ping timeout: 245 seconds]
00:49 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards
01:04 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
01:05 -!- 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:10 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit []
01:13 -!- _AlienTrooper is now known as AlienTrooper
01:14 -!- AlienTrooper [~Alien@2a00:d880:6:543::cd46] has quit [Changing host]
01:14 -!- AlienTrooper [~Alien@unaffiliated/alientrooper] has joined #bitcoin-wizards
01:34 -!- sCOGSBY [~uumdbmd@173.44.48.178] has quit [Read error: Connection reset by peer]
01:37 -!- adam3us [~Adium@unaffiliated/adam3us] has joined #bitcoin-wizards
01:44 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye]
01:45 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards
01:50 -!- 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:52 -!- moa [~kiwigb@opentransactions/dev/moa] has quit [Quit: Leaving.]
01:58 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.]
02:04 -!- roconnor [~roconnor@host-45-58-248-194.dyn.295.ca] has quit [Ping timeout: 256 seconds]
02:12 -!- liead [~adlie@unaffiliated/adlai] has quit [Ping timeout: 276 seconds]
02:16 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-jxtgnfhsdegmglez] has quit [Quit: Connection closed for inactivity]
02:26 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 272 seconds]
02:36 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
02:38 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-wizards
02:41 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-wizards
02:42 -!- wasi [~wasi@25.22.3.213.static.wline.lns.sme.cust.swisscom.ch] has joined #bitcoin-wizards
02:45 -!- tromp_ [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards
02:48 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-zkhqjzgotldxfdsm] has joined #bitcoin-wizards
02:49 -!- 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:55 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards
02:56 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
03:07 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-wizards
03:11 -!- LeMiner [LeMiner@unaffiliated/leminer] has joined #bitcoin-wizards
03:20 -!- ttttemp [~ttttemp@nb-10350.ethz.ch] has quit [Remote host closed the connection]
03:23 -!- grandmaster is now known as dansmith_btc
03:27 -!- ttttemp [~ttttemp@pc-5305.ethz.ch] has joined #bitcoin-wizards
03:31 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye]
03:35 -!- liead [~adlie@unaffiliated/adlai] has joined #bitcoin-wizards
03:40 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards
03:52 -!- voxelot [~voxelot@2605:e000:1525:802f:bf25:cb7d:8b4d:2d09] has quit [Ping timeout: 240 seconds]
03:58 -!- roman [~quassel@ANice-652-1-329-249.w86-193.abo.wanadoo.fr] has joined #bitcoin-wizards
04:03 -!- Peter00 [~Peter00@garza.riseup.net] has quit [Ping timeout: 256 seconds]
04:08 -!- roman [~quassel@ANice-652-1-329-249.w86-193.abo.wanadoo.fr] has quit [Read error: Connection reset by peer]
04:27 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
04:32 -!- liead [~adlie@unaffiliated/adlai] has quit [Read error: Connection reset by peer]
04:34 -!- liead [~adlie@unaffiliated/adlai] has joined #bitcoin-wizards
04:36 -!- MoALTz [~no@78-11-180-214.static.ip.netia.com.pl] has quit [Quit: Leaving]
04:38 -!- liead [~adlie@unaffiliated/adlai] has quit [Read error: Connection reset by peer]
04:39 -!- liead [~adlie@unaffiliated/adlai] has joined #bitcoin-wizards
04:50 -!- liead [~adlie@unaffiliated/adlai] has quit [Ping timeout: 240 seconds]
04:53 -!- nuke1989 [~nuke@176.92.98.61] has joined #bitcoin-wizards
05:00 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.]
05:01 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards
05:02 -!- p15x [~p15x@33.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-wizards
05:08 -!- liead [~adlie@unaffiliated/adlai] has joined #bitcoin-wizards
05:18 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 260 seconds]
05:20 -!- voxelot [~voxelot@2605:e000:1525:802f:18f3:1d02:b6ff:edea] has joined #bitcoin-wizards
05:33 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has quit [Remote host closed the connection]
05:36 -!- voxelot [~voxelot@2605:e000:1525:802f:18f3:1d02:b6ff:edea] has quit [Ping timeout: 250 seconds]
05:37 -!- adam3us [~Adium@unaffiliated/adam3us] has quit [Quit: Leaving.]
05:44 -!- 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:56 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 245 seconds]
05:59 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 245 seconds]
06:00 -!- 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:02 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-wizards
06:03 -!- p15x [~p15x@33.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 245 seconds]
06:08 -!- 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:20 -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards
06:30 -!- MoALTz [~no@78-11-180-214.static.ip.netia.com.pl] has quit [Quit: Leaving]
06:34 -!- Giszmo [~leo@pc-139-55-215-201.cm.vtr.net] has joined #bitcoin-wizards
06:39 -!- sparetire [~sparetire@unaffiliated/sparetire] has joined #bitcoin-wizards
06:43 -!- yorick__ is now known as yorick
06:44 -!- liead [~adlie@unaffiliated/adlai] has quit [Read error: Connection reset by peer]
06:47 -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards
06:47 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards
06:51 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Client Quit]
07:01 -!- roidster [~chatzilla@97-90-24-187.dhcp.mtpk.ca.charter.com] has joined #bitcoin-wizards
07:02 -!- roidster is now known as Guest70819
07:03 -!- Guest70819 is now known as roidster
07:03 -!- se3000 [~textual@38.125.163.25] has joined #bitcoin-wizards
07:04 -!- 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:08 -!- markus-k [~markus-k@141.91.210.210] has joined #bitcoin-wizards
07:13 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye]
07:15 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards
07:18 -!- nubbins` [~leel@unaffiliated/nubbins] has joined #bitcoin-wizards
07:19 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-wizards
07:20 -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 256 seconds]
07:21 -!- NewLiberty_ [~NewLibert@2602:306:b8e0:8160:b8e2:1c9c:fe32:8ba2] has joined #bitcoin-wizards
07:25 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
07:25 -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards
07:27 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye]
07:34 -!- bityogi [~textual@208-104-143-200.brvd.dsl.dyn.comporium.net] has joined #bitcoin-wizards
07:37 -!- fkhan [weechat@gateway/vpn/mullvad/x-tbjdntsyisiyoteo] has joined #bitcoin-wizards
07:45 -!- 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:47 -!- conner_ [~conner@18.111.107.174] has quit [Remote host closed the connection]
07:48 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-wizards
07:49 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
07:50 -!- tromp_ [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Ping timeout: 240 seconds]
07:52 -!- adam3us [~Adium@unaffiliated/adam3us] has joined #bitcoin-wizards
07:58 -!- bsm117532 [~mcelrath@38.121.165.30] has joined #bitcoin-wizards
08:02 -!- conner_ [~conner@dhcp-18-111-21-238.dyn.mit.edu] has joined #bitcoin-wizards
08:03 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-wizards
08:04 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
08:07 -!- voxelot [~voxelot@remote.digitalmoneycorp.com] has joined #bitcoin-wizards
08:10 -!- voxelot [~voxelot@remote.digitalmoneycorp.com] has quit [Changing host]
08:10 -!- voxelot [~voxelot@unaffiliated/voxelot] has joined #bitcoin-wizards
08:33 -!- earthris1 [~earthrise@S01065404a6902716.cg.shawcable.net] has joined #bitcoin-wizards
08:34 -!- lnovy [~lnovy@2002:4d57:f055::1] has quit [Ping timeout: 240 seconds]
08:36 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has joined #bitcoin-wizards
08:39 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards
08:42 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has quit [Ping timeout: 260 seconds]
08:47 -!- tromp_ [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards
08:52 -!- tromp_ [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Ping timeout: 264 seconds]
08:53 < 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:55 < zooko> wth
08:55  * zooko looks
08:56 < 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:58 < 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?
09:00 -!- phiche [~Adium@193.89.191.209] has quit [Ping timeout: 240 seconds]
09:01 < 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:03 < bsm117532> Well clearly the NSA is an adversary to basically everyone, and one shouldn't take their recommendations without independent analysis...
09:05 < 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:06 < zooko> lol
09:07 < 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:08 < zooko> *sigh*
09:08 < bsm117532> Hey why not sha-512?  No one wants factors of 3.
09:10 < 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:12 -!- 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:13 < 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:14 < 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:15 -!- 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:16 < bsm117532> Actually someone else in ##crypto found it...I just copied it here.
09:18 -!- 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:19 < bsm117532> maaku: Can you elaborate?  I'm not sure what you mean.
09:20 < 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:21 < 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:22 < 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:23 -!- 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:31 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards
09:32 < maaku> Well there are plusses and minuses to each approach.
09:39 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has joined #bitcoin-wizards
09:40 -!- phiche [~Adium@2.71.181.243.mobile.tre.se] has quit [Quit: Leaving.]
09:43 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has quit [Ping timeout: 245 seconds]
09:49 -!- 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:50 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-wizards
09:52 -!- phiche [~Adium@2.71.181.243.mobile.tre.se] has joined #bitcoin-wizards
09:57 -!- phiche [~Adium@2.71.181.243.mobile.tre.se] has quit [Quit: Leaving.]
09:58 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Ping timeout: 245 seconds]
10:03 -!- AusteritySucks [~Austerity@unaffiliated/austeritysucks] has quit [Ping timeout: 248 seconds]
10:04 -!- wasi [~wasi@25.22.3.213.static.wline.lns.sme.cust.swisscom.ch] has quit [Ping timeout: 256 seconds]
10:09 -!- 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:10 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
10:15 -!- AusteritySucks [~Austerity@unaffiliated/austeritysucks] has joined #bitcoin-wizards
10:19 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-wizards
10:21 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye]
10:27 -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards
10:29 -!- arubi_ is now known as arubi
10:30 -!- 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:31 -!- conner_ [~conner@31-35-123.wireless.csail.mit.edu] has joined #bitcoin-wizards
10:32 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards
10:34 -!- Dizzle [~Dizzle@104-6-36-162.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-wizards
10:38 -!- Oizopower [uid19103@gateway/web/irccloud.com/x-jlsudpcdyuodxkgu] has joined #bitcoin-wizards
10:49 -!- Tasoshi [~Tasoshi@unaffiliated/tasoshi] has quit [Read error: Connection reset by peer]
10:50 -!- Tasoshi [~Tasoshi@unaffiliated/tasoshi] has joined #bitcoin-wizards
10:55 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Remote host closed the connection]
10:56 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-wizards
11:08 -!- espes__ [~espes@205.185.120.132] has quit [Ping timeout: 250 seconds]
11:11 -!- phiche [~Adium@2.71.181.243.mobile.tre.se] has joined #bitcoin-wizards
11:16 -!- 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:17 < 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:19 < 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:21 -!- 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:24 -!- 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:29 -!- conner_ [~conner@31-35-123.wireless.csail.mit.edu] has quit [Remote host closed the connection]
11:38 -!- 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:42 < 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:43 < 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:46 -!- 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:47 -!- 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:48 -!- 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:49 < 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:50 < 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:51 < 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:53 < 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:55 < 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:58 -!- Peter00 [~Peter00@garza.riseup.net] has joined #bitcoin-wizards
11:59 -!- crowleyman [~crowleyma@185.6.187.38.pool.breezein.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
12:02 -!- e4xit [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has joined #bitcoin-wizards
12:03 -!- jposner_ [~jposner@172.98.67.11] has joined #bitcoin-wizards
12:04 < maaku> bsm117532: right, I suspect there's a fundamental reason why those proof sizes corrolate
12:06 < 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:08 < 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:09 -!- conner_ [~conner@dhcp-18-111-21-238.dyn.mit.edu] has quit [Ping timeout: 250 seconds]
12:10 < 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:11 -!- shesek [~shesek@bzq-84-110-211-141.cablep.bezeqint.net] has quit [Ping timeout: 240 seconds]
12:13 < maaku> Eliel_: you failed to provide justification for N-way channels in the first place
12:13 < maaku> why are they interesting?
12:17 -!- 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:18 < 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:19 -!- cfields [~quassel@unaffiliated/cfields] has quit [Ping timeout: 252 seconds]
12:19 -!- cfields [~quassel@unaffiliated/cfields] has joined #bitcoin-wizards
12:20 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards
12:21 -!- 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:24 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards
12:25 < 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:26 < 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:32 -!- 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:34 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.]
12:35 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards
12:36 -!- 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:38 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 245 seconds]
12:44 -!- conner_ [~conner@18.111.55.222] has joined #bitcoin-wizards
12:44 -!- LeMiner [LeMiner@unaffiliated/leminer] has joined #bitcoin-wizards
12:46 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 264 seconds]
12:51 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-wizards
12:54 -!- hazirafel [~hazirafel@213.8.204.43] has joined #bitcoin-wizards
12:57 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-xlmhricsrkukefwb] has joined #bitcoin-wizards
12:58 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards
13:00 -!- Dizzle [~Dizzle@104-6-36-162.lightspeed.austtx.sbcglobal.net] has quit [Quit: Leaving...]
13:03 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-wizards
13:04 -!- mengine [~mengine@251.92-221-142.customer.lyse.net] has quit [Remote host closed the connection]
13:08 < 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:11 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Ping timeout: 245 seconds]
13:14 -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards
13:16 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Quit: Leaving]
13:17 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has joined #bitcoin-wizards
13:21 -!- nabu [~nabu@179.43.169.226] has quit [Ping timeout: 248 seconds]
13:22 -!- nabu [~nabu@gateway/vpn/privateinternetaccess/nabu] has joined #bitcoin-wizards
13:25 -!- wasi [~wasi@pub082136074119.dh-hfc.datazug.ch] has joined #bitcoin-wizards
13:25 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-wizards
13:26 < 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:27 < bsm117532> dgenr8: UTXO (sub-)set is exactly txid range plus vout information.
13:28 < 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:29 -!- conner_ [~conner@18.111.55.222] has joined #bitcoin-wizards
13:30 -!- AusteritySucks [~Austerity@unaffiliated/austeritysucks] has quit [Ping timeout: 276 seconds]
13:35 < 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:42 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
13:44 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-wizards
13:47 -!- AusteritySucks [~Austerity@unaffiliated/austeritysucks] has joined #bitcoin-wizards
13:49 < teslax> oh! the onboard HD4600 seems to be dead to. hm. strange. very strange.
13:50 < teslax> vodka. NOW!
13:52 -!- teslax [~teslax@80-110-44-54.static.surfer.at] has left #bitcoin-wizards []
13:53 < fluffypony> wut
13:56 -!- Oizopower [uid19103@gateway/web/irccloud.com/x-jlsudpcdyuodxkgu] has quit [Quit: Connection closed for inactivity]
13:57 < 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...
14:03 -!- kelly [c0373725@gateway/web/freenode/ip.192.55.55.37] has joined #bitcoin-wizards
14:07 < 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:08 -!- 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:09 -!- AusteritySucks [~Austerity@unaffiliated/austeritysucks] has quit [Ping timeout: 240 seconds]
14:10 -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has quit [Ping timeout: 248 seconds]
14:13 < 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:14 -!- 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:15 < 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:16 < maaku> bsm117532: I'm confused as to why you need to "retrieve a proof from my peers for each input and output"
14:17 < maaku> bsm117532: In principle the only data you need is 32 bytes per input spent in the block
14:19 < 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:20 < bsm117532> maaku: How do you get down to 32 bytes?
14:21 -!- AusteritySucks [~Austerity@unaffiliated/austeritysucks] has joined #bitcoin-wizards
14:23 -!- murch [~murch@p4FE38FB9.dip0.t-ipconnect.de] has joined #bitcoin-wizards
14:30 -!- kelly [c0373725@gateway/web/freenode/ip.192.55.55.37] has quit [Ping timeout: 252 seconds]
14:31 -!- kelly [86868b46@gateway/web/freenode/ip.134.134.139.70] has joined #bitcoin-wizards
14:34 < 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:41 -!- 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:44 < 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:47 -!- 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:48 < 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:49 -!- 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:50 < CodeShark> We should probably stop thinking in terms of full node = validator and instead think full node = prover
14:51 < 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:52 -!- 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:53 < 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:54 < CodeShark> Validation cannot be directly incentivized whereas proofs can
14:55 < 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:56 < maaku> CodeShark: if they were truly decentralized you'd be creating your own proofs and not need to ask anyone else
14:57 < 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:58 < maaku> i suspect we are talking about different things
14:58 < maaku> :shrug:
15:01 < 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:03 < CodeShark> then by induction if block n is valid and transitions are valid, then block n + k is valid
15:04 < CodeShark> Currently the proofs of valid transitions are too big
15:09 -!- kelly [86868b46@gateway/web/freenode/ip.134.134.139.70] has quit [Ping timeout: 252 seconds]
15:12 < CodeShark> to prevent nodes from paracetizing full prover nodes we can require micropayments
15:12 < CodeShark> *parasetizing
15:13 -!- 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:14 < 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:16 -!- 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:17 < CodeShark> You get a tragedy of the commons situation
15:18 < 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:19 < 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:20 < CodeShark> Let's throw out the "full node" concept entirely in that case :)
15:20 < maaku> right
15:21 < dgenr8> you could pay for a proof that an input is valid, and pay extra for the proof that it is spent
15:22 -!- wasi [~wasi@pub082136074119.dh-hfc.datazug.ch] has quit [Ping timeout: 248 seconds]
15:23 -!- Emcy [~MC@unaffiliated/mc1984] has quit [Ping timeout: 256 seconds]
15:29 < 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:30 < maaku> bsm117532: what would a 'proof of inclusion' (or exclusion) look like using iSHAKE128?
15:35 -!- Emcy [~MC@unaffiliated/mc1984] has joined #bitcoin-wizards
15:37 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has quit [Remote host closed the connection]
15:39 -!- wasi [~wasi@25.22.3.213.static.wline.lns.sme.cust.swisscom.ch] has joined #bitcoin-wizards
15:40 -!- veleiro [~veleiro@fsf/member/veleiro] has quit [Ping timeout: 276 seconds]
15:40 -!- veleiro [~veleiro@fsf/member/veleiro] has joined #bitcoin-wizards
15:41 -!- HostFat [~HostFat@2-235-224-2.ip230.fastwebnet.it] has joined #bitcoin-wizards
15:42 -!- adnn [adnn@gateway/vpn/mullvad/x-rrwhoflrihjxclbr] has joined #bitcoin-wizards
15:52 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
15:54 -!- veleiro [~veleiro@fsf/member/veleiro] has quit [Ping timeout: 272 seconds]
16:05 -!- belcher [~user@unaffiliated/belcher] has quit [Read error: Connection reset by peer]
16:06 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.]
16:06 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-wizards
16:09 < 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:11 -!- 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:12 -!- 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:16 -!- Jeremy_Rand_2 [~user@ip68-97-38-24.ok.ok.cox.net] has quit [Ping timeout: 260 seconds]
16:17 < stevenroose> maaku, like what?
16:17 < maaku> https://bitcointalk.org/index.php?topic=290971.0
16:18 < 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:19 < 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:20 < maaku> (this is what lighthouse uses)
16:20 < maaku> but in real life you often care about 2+ outputs
16:21 < 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:22 -!- 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:23 < CodeShark> removes a symmetry
16:24 < CodeShark> Allows more compact representation and improves privacy
16:25 < CodeShark> and makes the representation unique
16:34 < stevenroose> The reason I was thinking about this was for outsourcing tx broadcasting for timelocked contracts for lightning
16:35 < 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:36 < stevenroose> So yes, a more generic way should be nice, since there will probably be more inputs and outputs involved
16:40 < wasi> a fix sorting mechanism for inputs and outputs is required anyway in order to eliminate transaction malleability, or not?
16:41 -!- Jeremy_Rand_2 [~user@172.58.104.114] has joined #bitcoin-wizards
16:46 -!- Peter00 [~Peter00@garza.riseup.net] has quit [Quit: Peter00]
16:50 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 272 seconds]
16:52 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
16:53 -!- 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:55 -!- ieephmm [~ieeehmm@cpe-172-90-241-198.socal.res.rr.com] has quit [Ping timeout: 256 seconds]
16:58 -!- voxelot [~voxelot@unaffiliated/voxelot] has quit [Remote host closed the connection]
17:01 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 250 seconds]
17:05 -!- murch [~murch@p4FE38FB9.dip0.t-ipconnect.de] has quit [Quit: Leaving.]
17:09 -!- jcluck [~cluckj@pool-108-16-231-242.phlapa.fios.verizon.net] has joined #bitcoin-wizards
17:11 -!- cluckj [~cluckj@pool-108-16-231-242.phlapa.fios.verizon.net] has quit [Ping timeout: 256 seconds]
17:13 < 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:14 < Taek> So, it doesn't matter who submits the proof, the same person gets paid
17:25 -!- 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:27 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam]
17:29 -!- tromp_ [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards
17:32 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards
17:33 -!- Jeremy_Rand_2 [~user@172.58.104.114] has joined #bitcoin-wizards
17:40 -!- tromp_ [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Remote host closed the connection]
17:48 -!- bityogi [~textual@208-104-143-200.brvd.dsl.dyn.comporium.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
17:50 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 240 seconds]
17:56 -!- HostFat [~HostFat@2-235-224-2.ip230.fastwebnet.it] has quit [Quit: Leaving]
17:58 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-nygtowczsdnvwwnk] has quit [Quit: Connection closed for inactivity]
18:01 < 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:02 < 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:03 -!- jcluck is now known as cluckj
18:03 -!- Howdy__ [~Howdy---@testbed-users.tor-exit.calyxinstitute.org] has joined #bitcoin-wizards
18:05 < 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:08 < 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:09 -!- 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:10 < 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:11 -!- chris___ [~chris@208.185.52.110] has joined #bitcoin-wizards
18:13 -!- Jeremy_Rand_2 [~user@172.58.104.114] has quit [Ping timeout: 260 seconds]
18:14 -!- chris___ is now known as glitch003
18:15 < 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:16 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam]
18:18 -!- adnn_ [~adnn@cpe-158-222-198-108.nyc.res.rr.com] has joined #bitcoin-wizards
18:22 -!- adnn [adnn@gateway/vpn/mullvad/x-rrwhoflrihjxclbr] has quit [Ping timeout: 252 seconds]
18:22 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
18:23 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
18:27 -!- conner_ [~conner@c-98-216-48-105.hsd1.ma.comcast.net] has joined #bitcoin-wizards
18:31 -!- bildramer [~bildramer@p5DC8ADCC.dip0.t-ipconnect.de] has quit [Ping timeout: 256 seconds]
18:33 -!- bildramer [~bildramer@p5DC8ADCC.dip0.t-ipconnect.de] has joined #bitcoin-wizards
18:40 -!- espes__ [~espes@205.185.120.132] has joined #bitcoin-wizards
18:42 -!- Jeremy_Rand_2 [~user@172.58.104.114] has joined #bitcoin-wizards
18:43 < 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:45 < 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:47 < 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:48 < 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:49 < 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:50 -!- 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:51 < bsm1175321> Taek the 1/3 is related to the notion that nodes can lie.
18:51 < bsm1175321> It's not a redundancy factor.
18:52 < 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:53 -!- 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:54 -!- 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:55 < 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:56 < 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:57 < 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:59 < 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?
19:02 -!- 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:03 -!- bityogi [~textual@208-104-143-200.brvd.dsl.dyn.comporium.net] has joined #bitcoin-wizards
19:10 -!- conner_ [~conner@c-98-216-48-105.hsd1.ma.comcast.net] has quit [Remote host closed the connection]
19:13 -!- 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:15 -!- glitch00_ [~chris@208.185.52.110] has quit []
19:15 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 240 seconds]
19:19 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has quit [Remote host closed the connection]
19:20 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-wizards
19:20 < phantomcircuit> bsm1175321, why?
19:22 < 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:23 < phantomcircuit> Taek, what's he talking about?
19:23 < bsm1175321> phantomcircuit: can you ask a more specific question?  ;-)  -- Sharding the blockchain.
19:24 < 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:25 < 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:26 < 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:27 -!- 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:28 < 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:29 < 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:30 < 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:33 < 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:34 < 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:35 < 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:36 < 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:37 < 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:38 < 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:39 < 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:40 < 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:41 < 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:42 < 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:43 < 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:44 < 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:45 < 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:46 < 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:47 < phantomcircuit> bsm1175321, would have to include the fraud proofs?
19:47 < phantomcircuit> wait what
19:48 < 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:49 < 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:52 < phantomcircuit> bsm1175321, i dont think anybody has actually constructed a system in which you can prove non-fraud completely
19:54 < 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:55 < 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:56 < 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:57 < 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:58 < 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:59 < 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.
20:00 < 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:01 < 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:02 -!- NewLiberty_ [~NewLibert@2602:304:cff8:1580:bd7d:1c91:2a8d:9bd7] has joined #bitcoin-wizards
20:03 < 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:04 < 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:05 < 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:06 < 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:07 < 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:08 < 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:09 -!- 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:10 < 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:11 < 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:12 < 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:13 < 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:14 < 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:15 < 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:19 -!- brg444 [415e49c7@gateway/web/freenode/ip.65.94.73.199] has quit [Ping timeout: 252 seconds]
20:20 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has joined #bitcoin-wizards
20:22 < phantomcircuit> bsm1175321, zk-SNARKS for things we cannot do otherwise seems like a not-bad idea
20:23 < bsm1175321> phantomcircuit: I'm willing to accept log(n) in the meantime, and plan on soft-forking in an O(1) zk-SNARK.  ;-)
20:24 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has quit [Ping timeout: 240 seconds]
20:26 < amiller> hooray
20:27 < 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:28 < 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:29 < bsm1175321> Clearly it's nearly midnight where I am and I'm getting loopy.
20:29 < petertodd> bsm1175321: ACK
20:30 < 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:31 < bsm1175321> The gin has NOTHING to do with it.
20:32 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 250 seconds]
20:34 -!- 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:36  * 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:39 -!- 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:52 -!- frankenmint [~frankenmi@174-25-38-39.ptld.qwest.net] has joined #bitcoin-wizards
20:56 -!- sCOGSBY [~uumdbmd@173.44.48.178] has joined #bitcoin-wizards
21:03 -!- nubbins` [~leel@unaffiliated/nubbins] has quit [Quit: Quit]
21:04 -!- nubbins` [~leel@unaffiliated/nubbins] has joined #bitcoin-wizards
21:22 -!- Jeremy_Rand_2_ [~user@ip68-97-38-24.ok.ok.cox.net] has joined #bitcoin-wizards
21:36 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
21:38 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-wizards
21:38 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
21:40 -!- nuke1989 [~nuke@176.92.98.61] has quit [Remote host closed the connection]
21:41 -!- tromp_ [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Remote host closed the connection]
21:53 -!- roidster [~chatzilla@97-90-24-187.dhcp.mtpk.ca.charter.com] has quit [Ping timeout: 276 seconds]
21:57 -!- Giszmo [~leo@pc-139-55-215-201.cm.vtr.net] has quit [Quit: Leaving.]
22:01 -!- nubbins` [~leel@unaffiliated/nubbins] has quit [Quit: Quit]
22:05 -!- nubbins` [~leel@unaffiliated/nubbins] has joined #bitcoin-wizards
22:05 -!- nubbins` [~leel@unaffiliated/nubbins] has quit [Client Quit]
22:08 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
22:10 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-wizards
22:30 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
22:32 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-wizards
22:41 -!- tromp_ [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards
22:46 -!- tromp_ [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Ping timeout: 252 seconds]
22:54 < Luke-Jr> bsm1175321: lolwut
22:57 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-jlzykkxpyjvehcgh] has joined #bitcoin-wizards
22:58 < phantomcircuit> Luke-Jr, he's marveling at being able to talk to me, dont be jealous
22:58  * phantomcircuit runs away
23:00 < 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:02 < aj> Luke-Jr: but maybe he has an ex-girlfriend whose ex-boyfriend was Dashing? that's pretty close, right?
23:04 < Luke-Jr> no
23:14 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
23:23 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
23:25 -!- AusteritySucks [~Austerity@unaffiliated/austeritysucks] has quit [Ping timeout: 248 seconds]
23:25 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-wizards
23:35 -!- voxelot [~voxelot@2605:e000:1525:802f:18f3:1d02:b6ff:edea] has quit [Ping timeout: 252 seconds]
23:38 -!- AusteritySucks [~Austerity@unaffiliated/austeritysucks] has joined #bitcoin-wizards
23:43 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 272 seconds]
23:48 -!- AusteritySucks [~Austerity@unaffiliated/austeritysucks] has quit [Ping timeout: 250 seconds]
23:51 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
23:53 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-wizards
23:55 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards
23:56 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 276 seconds]
--- Log closed Tue Feb 09 00:00:28 2016