| --- Day changed Tue Dec 23 2014 | ||
| -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-wizards | 00:06 | |
| -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has quit [Changing host] | 00:06 | |
| -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-wizards | 00:06 | |
| -!- pavel_ [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-wizards | 00:09 | |
| -!- pavel_ [~paveljani@79-98-72-216.sys-data.com] has quit [Client Quit] | 00:10 | |
| -!- pavel_ [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-wizards | 00:10 | |
| -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Disconnected by services] | 00:11 | |
| -!- pavel_ [~paveljani@79-98-72-216.sys-data.com] has quit [Changing host] | 00:11 | |
| -!- pavel_ [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-wizards | 00:11 | |
| -!- pavel_ [~paveljani@unaffiliated/paveljanik] has quit [Client Quit] | 00:12 | |
| -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-wizards | 00:12 | |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards | 00:15 | |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards | 00:22 | |
| -!- gues [~gues@cpe-66-68-54-206.austin.res.rr.com] has quit [Ping timeout: 245 seconds] | 00:24 | |
| -!- NewLiberty_ [~NewLibert@2602:304:cff8:1580:6156:df06:de8a:8e51] has joined #bitcoin-wizards | 00:25 | |
| -!- gues [gues@gateway/vpn/mullvad/x-bndujvmfjjohbope] has joined #bitcoin-wizards | 00:25 | |
| -!- d1ggy [~d1ggy@dslb-088-073-244-129.088.073.pools.vodafone-ip.de] has joined #bitcoin-wizards | 00:26 | |
| -!- NewLiberty [~NewLibert@2602:304:cff8:1580:6156:df06:de8a:8e51] has quit [Ping timeout: 258 seconds] | 00:26 | |
| -!- MRL-Relay [~mrl-relay@coreteam.monero.cc] has quit [Ping timeout: 250 seconds] | 00:34 | |
| -!- fluffypony [~fluffypon@unaffiliated/fluffypony] has quit [Ping timeout: 250 seconds] | 00:35 | |
| -!- MRL-Relay [~mrl-relay@coreteam.monero.cc] has joined #bitcoin-wizards | 00:40 | |
| -!- fluffypony [~fluffypon@unaffiliated/fluffypony] has joined #bitcoin-wizards | 00:40 | |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Remote host closed the connection] | 00:43 | |
| maaku | ok, yes i think there was an error in the code | 00:44 |
|---|---|---|
| -!- d1ggy [~d1ggy@dslb-088-073-244-129.088.073.pools.vodafone-ip.de] has quit [Ping timeout: 244 seconds] | 00:46 | |
| -!- SubCreative is now known as Sub|zzz | 00:48 | |
| -!- Sub|zzz is now known as SubCreative | 00:49 | |
| -!- SubCreative is now known as Sub|zzz | 00:49 | |
| -!- d1ggy [~d1ggy@dslb-088-073-244-129.088.073.pools.vodafone-ip.de] has joined #bitcoin-wizards | 01:00 | |
| -!- 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 | |
| -!- CoinMuncher [~jannes@178.132.211.90] has joined #bitcoin-wizards | 01:05 | |
| -!- adam3us [~Adium@host-92-18-108-128.as13285.net] has joined #bitcoin-wizards | 01:08 | |
| -!- hashtag_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards | 01:11 | |
| -!- adam3us1 [~Adium@host-92-18-108-128.as13285.net] has joined #bitcoin-wizards | 01:12 | |
| -!- adam3us [~Adium@host-92-18-108-128.as13285.net] has quit [Read error: Connection reset by peer] | 01:12 | |
| MRL-Relay | [smooth] .win1 | 01:20 |
| -!- gues [gues@gateway/vpn/mullvad/x-bndujvmfjjohbope] has quit [Ping timeout: 250 seconds] | 01:35 | |
| -!- MoALTz_ [~no@user-164-126-31-182.play-internet.pl] has quit [Quit: Leaving] | 01:37 | |
| -!- MoALTz [~no@user-164-126-31-182.play-internet.pl] has joined #bitcoin-wizards | 01:37 | |
| -!- NewLiberty_ [~NewLibert@2602:304:cff8:1580:6156:df06:de8a:8e51] has quit [Ping timeout: 258 seconds] | 01:38 | |
| -!- vmatekole [~vmatekole@p5DC473BE.dip0.t-ipconnect.de] has joined #bitcoin-wizards | 01:45 | |
| -!- vmatekole [~vmatekole@p5DC473BE.dip0.t-ipconnect.de] has quit [Remote host closed the connection] | 01:46 | |
| -!- vmatekole [~vmatekole@p5DC473BE.dip0.t-ipconnect.de] has joined #bitcoin-wizards | 01:47 | |
| -!- gues [~gues@cpe-66-68-54-206.austin.res.rr.com] has joined #bitcoin-wizards | 01:47 | |
| -!- GAit [~lnahum@enki.greenaddressit.p3.tiktalik.io] has quit [Remote host closed the connection] | 02:27 | |
| -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards | 02:36 | |
| -!- hashtag_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 240 seconds] | 02:45 | |
| -!- Baz__ [~Baz@70.81.31.147] has joined #bitcoin-wizards | 02:47 | |
| -!- Baz__ [~Baz@70.81.31.147] has quit [Client Quit] | 02:48 | |
| -!- Baz__ [~Baz@modemcable147.31-81-70.mc.videotron.ca] has joined #bitcoin-wizards | 02:48 | |
| -!- hashtag_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards | 02:49 | |
| -!- afk11 [~androirc@108.61.122.195] has joined #bitcoin-wizards | 02:52 | |
| -!- fanquake [~anonymous@unaffiliated/fanquake] has joined #bitcoin-wizards | 02:55 | |
| -!- jtimon [~quassel@159.pool85-59-61.dynamic.orange.es] has joined #bitcoin-wizards | 02:55 | |
| -!- bosma [~bosma@S01067cb21bda6531.vc.shawcable.net] has quit [Quit: Leaving] | 03:01 | |
| -!- bosma [~bosma@S01067cb21bda6531.vc.shawcable.net] has joined #bitcoin-wizards | 03:02 | |
| -!- afk11 [~androirc@108.61.122.195] has quit [Ping timeout: 244 seconds] | 03:09 | |
| -!- belcher [~belcher-s@5ec3b035.skybroadband.com] has joined #bitcoin-wizards | 03:09 | |
| -!- belcher [~belcher-s@5ec3b035.skybroadband.com] has quit [Changing host] | 03:10 | |
| -!- belcher [~belcher-s@unaffiliated/belcher] has joined #bitcoin-wizards | 03:10 | |
| -!- afk11 [~androirc@108.61.122.156] has joined #bitcoin-wizards | 03:10 | |
| -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Ping timeout: 244 seconds] | 03:13 | |
| -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has joined #bitcoin-wizards | 03:22 | |
| -!- iang [~iang@188.29.165.77.threembb.co.uk] has joined #bitcoin-wizards | 03:30 | |
| -!- Quanttek [~quassel@ip1f12ed87.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards | 03:30 | |
| -!- afk11 [~androirc@108.61.122.156] has quit [Remote host closed the connection] | 03:34 | |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection] | 03:36 | |
| -!- afk11 [~androirc@108.61.122.156] has joined #bitcoin-wizards | 03:36 | |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards | 03:36 | |
| -!- gues [~gues@cpe-66-68-54-206.austin.res.rr.com] has quit [Ping timeout: 240 seconds] | 03:37 | |
| -!- gues [~gues@193.138.219.233] has joined #bitcoin-wizards | 03:39 | |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Ping timeout: 256 seconds] | 03:41 | |
| -!- Grishnakh [~grishnakh@dsl-espbrasgw1-50dfb6-218.dhcp.inet.fi] has quit [Quit: Leaving] | 03:42 | |
| -!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has joined #bitcoin-wizards | 03:43 | |
| -!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has quit [Changing host] | 03:43 | |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards | 03:43 | |
| -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-wizards | 03:51 | |
| -!- iang [~iang@188.29.165.77.threembb.co.uk] has quit [Quit: iang] | 03:51 | |
| -!- Quanttek [~quassel@ip1f12ed87.dynamic.kabel-deutschland.de] has quit [Ping timeout: 250 seconds] | 03:53 | |
| -!- iang [~iang@188.29.165.77.threembb.co.uk] has joined #bitcoin-wizards | 03:54 | |
| -!- iang [~iang@188.29.165.77.threembb.co.uk] has quit [Client Quit] | 03:58 | |
| -!- adam3us [~Adium@host-92-19-8-76.as13285.net] has joined #bitcoin-wizards | 04:05 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards | 04:07 | |
| -!- adam3us1 [~Adium@host-92-18-108-128.as13285.net] has quit [Ping timeout: 240 seconds] | 04:08 | |
| -!- Netsplit *.net <-> *.split quits: atgreen, Sub|zzz, bosma, lclc_bnc, Cory, belcher, c0rw1n, kobud, shesek, phantomcircuit, (+28 more, use /NETSPLIT to show all of them) | 04:24 | |
| --- Log closed Tue Dec 23 04:24:28 2014 | ||
| --- Log opened Tue Dec 23 04:25:05 2014 | ||
| -!- kanzure [~kanzure@unaffiliated/kanzure] has joined #bitcoin-wizards | 04:25 | |
| -!- Irssi: #bitcoin-wizards: Total of 141 nicks [1 ops, 0 halfops, 0 voices, 140 normal] | 04:25 | |
| -!- bosma [~bosma@S01067cb21bda6531.vc.shawcable.net] has joined #bitcoin-wizards | 04:25 | |
| -!- hashtag_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards | 04:25 | |
| -!- fluffypony [~fluffypon@unaffiliated/fluffypony] has joined #bitcoin-wizards | 04:25 | |
| -!- alferz [~alferz@unaffiliated/alfer] has joined #bitcoin-wizards | 04:25 | |
| -!- kobud [wq@unaffiliated/fluffybunny] has joined #bitcoin-wizards | 04:25 | |
| -!- espes__ [~espes@205.185.120.132] has joined #bitcoin-wizards | 04:25 | |
| -!- c0rw1n [~c0rw1n@174.179-67-87.adsl-dyn.isp.belgacom.be] has joined #bitcoin-wizards | 04:25 | |
| -!- Iriez [wario@distribution.xbins.org] has joined #bitcoin-wizards | 04:25 | |
| -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-wizards | 04:25 | |
| -!- Baz__ [~Baz@modemcable147.31-81-70.mc.videotron.ca] has joined #bitcoin-wizards | 04:26 | |
| -!- d1ggy [~d1ggy@dslb-088-073-244-129.088.073.pools.vodafone-ip.de] has joined #bitcoin-wizards | 04:26 | |
| -!- ryanxcharles [~ryanxchar@2601:9:4680:dd0:958b:8451:87eb:ce30] has joined #bitcoin-wizards | 04:26 | |
| -!- ahmed_ [sid14086@gateway/web/irccloud.com/x-zsjigvgjemkosldq] has joined #bitcoin-wizards | 04:26 | |
| -!- Muis [sid26074@gateway/web/irccloud.com/x-lajwkavlumxcrmmk] has joined #bitcoin-wizards | 04:26 | |
| -!- mappum [sid43795@gateway/web/irccloud.com/x-vlompupjtcrcyval] has joined #bitcoin-wizards | 04:26 | |
| -!- michagogo [uid14316@wikia/Michagogo] has joined #bitcoin-wizards | 04:26 | |
| -!- [\\\] [\\\@unaffiliated/imsaguy] has joined #bitcoin-wizards | 04:26 | |
| -!- hashtagg [~hashtagg_@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards | 04:26 | |
| -!- NikolaiToryzin [~stqism@freebsd/user/stqism] has joined #bitcoin-wizards | 04:26 | |
| -!- isis [~isis@abulafia.patternsinthevoid.net] has joined #bitcoin-wizards | 04:26 | |
| -!- lclc_bnc [~lclc@bothniafur.com] has joined #bitcoin-wizards | 04:26 | |
| -!- kyletorpey [~kyle@c-24-131-0-5.hsd1.va.comcast.net] has joined #bitcoin-wizards | 04:26 | |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards | 04:26 | |
| -!- Starduster [~guest@unaffiliated/starduster] has joined #bitcoin-wizards | 04:26 | |
| -!- morcos [~morcos@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-wizards | 04:26 | |
| -!- hollandais [~irenacob@li629-190.members.linode.com] has joined #bitcoin-wizards | 04:26 | |
| -!- Cory [~Cory@unaffiliated/cory] has joined #bitcoin-wizards | 04:26 | |
| -!- optimator [~optimator@unaffiliated/optimator] has joined #bitcoin-wizards | 04:26 | |
| -!- shesek [~shesek@77.126.5.17] has joined #bitcoin-wizards | 04:26 | |
| -!- Graet [~Graet@unaffiliated/graet] has joined #bitcoin-wizards | 04:26 | |
| -!- mr_burdell [~mr_burdel@unaffiliated/mr-burdell/x-7609603] has joined #bitcoin-wizards | 04:26 | |
| -!- phantomcircuit [~phantomci@smartcontracts.us] has joined #bitcoin-wizards | 04:26 | |
| -!- pi07r [~pi07r@f212009.upc-f.chello.nl] has joined #bitcoin-wizards | 04:26 | |
| -!- mkarrer [~mkarrer@135.Red-83-52-38.dynamicIP.rima-tde.net] has joined #bitcoin-wizards | 04:26 | |
| -!- Emcy [~MC@unaffiliated/mc1984] has joined #bitcoin-wizards | 04:26 | |
| -!- nsh_ [~nsh@host86-154-43-227.range86-154.btcentralplus.com] has joined #bitcoin-wizards | 04:26 | |
| -!- jchp [~jchp@unaffiliated/jchp] has joined #bitcoin-wizards | 04:26 | |
| -!- LarsLarsen [~lars@50.161.197.33] has joined #bitcoin-wizards | 04:26 | |
| -!- fenn [~fenn@unaffiliated/fenn] has joined #bitcoin-wizards | 04:26 | |
| -!- Krellan [~Krellan@24.4.193.132] has joined #bitcoin-wizards | 04:26 | |
| -!- warren [~warren@fedora/wombat/warren] has joined #bitcoin-wizards | 04:26 | |
| -!- ahmed_ [sid14086@gateway/web/irccloud.com/x-zsjigvgjemkosldq] has quit [Max SendQ exceeded] | 04:27 | |
| -!- belcher [~belcher-s@unaffiliated/belcher] has joined #bitcoin-wizards | 04:28 | |
| -!- Guest22056 [~omni@ip68-4-111-228.oc.oc.cox.net] has joined #bitcoin-wizards | 04:28 | |
| -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-wizards | 04:28 | |
| -!- atgreen [~user@CPE687f74122463-CM84948c2e0610.cpe.net.cable.rogers.com] has joined #bitcoin-wizards | 04:28 | |
| -!- Sub|zzz [~SubCreati@unaffiliated/cannacoin] has joined #bitcoin-wizards | 04:28 | |
| -!- gavinandresen [~gavin@unaffiliated/gavinandresen] has joined #bitcoin-wizards | 04:28 | |
| -!- sl01_ [~sl01@li431-44.members.linode.com] has joined #bitcoin-wizards | 04:28 | |
| -!- luny [~luny@unaffiliated/luny] has joined #bitcoin-wizards | 04:28 | |
| -!- ahmed_ [sid14086@gateway/web/irccloud.com/x-apsvfkyoldrjqvvf] has joined #bitcoin-wizards | 04:29 | |
| -!- c0rw1n [~c0rw1n@174.179-67-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 244 seconds] | 04:29 | |
| -!- Irssi: Join to #bitcoin-wizards was synced in 521 secs | 04:33 | |
| -!- c0rw1n [~c0rw1n@174.179-67-87.adsl-dyn.isp.belgacom.be] has joined #bitcoin-wizards | 04:33 | |
| -!- hearn [~mike@cpc8-macc3-2-0-cust245.1-3.cable.virginm.net] has joined #bitcoin-wizards | 04:34 | |
| -!- MoALTz [~no@user-164-126-31-182.play-internet.pl] has quit [Quit: Leaving] | 04:45 | |
| -!- gues [~gues@193.138.219.233] has quit [Ping timeout: 265 seconds] | 04:49 | |
| -!- gues [gues@gateway/vpn/mullvad/x-yqxywptftfdtuplv] has joined #bitcoin-wizards | 04:51 | |
| -!- iang [~iang@188.29.164.243.threembb.co.uk] has joined #bitcoin-wizards | 04:52 | |
| -!- hearn [~mike@cpc8-macc3-2-0-cust245.1-3.cable.virginm.net] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 04:52 | |
| -!- hashtag_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 244 seconds] | 04:55 | |
| -!- cluckj [~cluckj@cpe-24-92-48-18.nycap.res.rr.com] has joined #bitcoin-wizards | 04:58 | |
| -!- ahmed_ is now known as ahmed__ | 04:59 | |
| -!- ahmed__ [sid14086@gateway/web/irccloud.com/x-apsvfkyoldrjqvvf] has quit [Excess Flood] | 04:59 | |
| -!- ahmed_ [sid14086@gateway/web/irccloud.com/x-hjnhqwvjimdbiqri] has joined #bitcoin-wizards | 05:01 | |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection] | 05:04 | |
| -!- belcher [~belcher-s@unaffiliated/belcher] has quit [Ping timeout: 252 seconds] | 05:06 | |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards | 05:08 | |
| -!- NewLiberty_ [~NewLibert@2602:304:cff8:1580:a9dd:bf2d:7ebb:12ec] has joined #bitcoin-wizards | 05:08 | |
| -!- d1ggy [~d1ggy@dslb-088-073-244-129.088.073.pools.vodafone-ip.de] has quit [Quit: Leaving] | 05:09 | |
| -!- NewLiberty_ is now known as NewLiberty | 05:10 | |
| -!- belcher [~belcher-s@unaffiliated/belcher] has joined #bitcoin-wizards | 05:13 | |
| -!- Burrito [~Burrito@unaffiliated/burrito] has joined #bitcoin-wizards | 05:15 | |
| -!- iang [~iang@188.29.164.243.threembb.co.uk] has quit [Quit: iang] | 05:18 | |
| -!- aburan28 [~ubuntu@static-108-45-93-73.washdc.fios.verizon.net] has quit [Ping timeout: 256 seconds] | 05:22 | |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [] | 05:25 | |
| -!- iang [~iang@188.29.164.243.threembb.co.uk] has joined #bitcoin-wizards | 05:26 | |
| -!- gues [gues@gateway/vpn/mullvad/x-yqxywptftfdtuplv] has quit [Ping timeout: 245 seconds] | 05:26 | |
| -!- gues [~gues@cpe-66-68-54-206.austin.res.rr.com] has joined #bitcoin-wizards | 05:27 | |
| -!- belcher [~belcher-s@unaffiliated/belcher] has quit [Ping timeout: 256 seconds] | 05:27 | |
| -!- belcher [~belcher-s@unaffiliated/belcher] has joined #bitcoin-wizards | 05:28 | |
| -!- Profreid [~Profreitt@179.43.148.66] has joined #bitcoin-wizards | 05:42 | |
| -!- Logicwax [~Logicwax@c-50-161-23-192.hsd1.ca.comcast.net] has quit [Quit: rm -rf /] | 05:47 | |
| -!- jps [~Jud@cpe-74-72-116-143.nyc.res.rr.com] has joined #bitcoin-wizards | 05:52 | |
| -!- hashtag_ [~hashtag@cpe-98-157-219-44.ma.res.rr.com] has joined #bitcoin-wizards | 05:52 | |
| nsh | gmaxwell, can you think of a pathological case in which a low-density parity-check algorithm would be nonterminating? | 05:59 |
| gmaxwell | nsh: does not compute. Optimal decode for arbritary inputs isn't tractable. Any decoder is approximate, and time bounded. | 06:00 |
| nsh | (decoding algorithm for a signal encoded with an LDPC encoding) | 06:00 |
| nsh | ah, okay. was trying to parse someone's caveat | 06:00 |
| gmaxwell | (well of course most of the time the decoder won't hit its timebound, it'll actually converge) | 06:00 |
| nsh | "LDPC is a more efficient extension that reaches the Shannon limit [...] harder to do by hand, and the decoding algorithms are iterative and possibly nonterminating" | 06:01 |
| nsh | wasn't intuitive to me how you'd get a nonterminating case | 06:01 |
| gmaxwell | nsh: a naieve unbounded belief propagation could end up in a loop. | 06:01 |
| gmaxwell | "so don't do that" | 06:01 |
| nsh | hmm | 06:01 |
| nsh | surely there's a maximum nonlooping number of iterations. is that the time-bounding? | 06:02 |
| -!- Logicwax [~Logicwax@c-50-161-23-192.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 06:02 | |
| gmaxwell | in any sane implementation! | 06:02 |
| * nsh nods | 06:02 | |
| gmaxwell | even if you didn't care about it being finitely timed, you could implement loop detection cheaply and then it would be technically terminating. But that all seems silly, you put a bound on it and accept that there are some inputs that it could have corrected if it spent just a bit more time on it before giving up. | 06:03 |
| nsh | hmm | 06:05 |
| -!- Logicwax [~Logicwax@c-50-161-23-192.hsd1.ca.comcast.net] has quit [Quit: rm -rf /] | 06:09 | |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards | 06:14 | |
| -!- coiner [~linker@113.161.87.238] has quit [Ping timeout: 244 seconds] | 06:14 | |
| -!- Logicwax [~Logicwax@c-50-161-23-192.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 06:18 | |
| -!- fanquake [~anonymous@unaffiliated/fanquake] has quit [Quit: fanquake] | 06:19 | |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Remote host closed the connection] | 06:25 | |
| -!- hearn [~mike@cpc8-macc3-2-0-cust245.1-3.cable.virginm.net] has joined #bitcoin-wizards | 06:32 | |
| -!- vmatekol_ [~vmatekole@p5DC473BE.dip0.t-ipconnect.de] has joined #bitcoin-wizards | 06:36 | |
| -!- vmatekole [~vmatekole@p5DC473BE.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] | 06:38 | |
| -!- belcher [~belcher-s@unaffiliated/belcher] has quit [Read error: Connection reset by peer] | 06:42 | |
| -!- coiner [~linker@1.54.73.86] has joined #bitcoin-wizards | 06:44 | |
| -!- gues [~gues@cpe-66-68-54-206.austin.res.rr.com] has quit [Ping timeout: 252 seconds] | 06:44 | |
| -!- vmatekol_ [~vmatekole@p5DC473BE.dip0.t-ipconnect.de] has quit [Remote host closed the connection] | 06:50 | |
| -!- vmatekole [~vmatekole@p5DC473BE.dip0.t-ipconnect.de] has joined #bitcoin-wizards | 06:51 | |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards | 06:56 | |
| -!- lnovy [~lnovy@2002:4d57:f055::1] has quit [Ping timeout: 272 seconds] | 06:58 | |
| -!- Logicwax [~Logicwax@c-50-161-23-192.hsd1.ca.comcast.net] has quit [Ping timeout: 250 seconds] | 06:58 | |
| -!- maraoz [~maraoz@181.29.97.171] has joined #bitcoin-wizards | 06:59 | |
| -!- zz_lnovy [~lnovy@2002:4d57:f055::1] has joined #bitcoin-wizards | 07:00 | |
| -!- zz_lnovy is now known as lnovy | 07:00 | |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Remote host closed the connection] | 07:04 | |
| -!- Logicwax [~Logicwax@c-50-161-23-192.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 07:12 | |
| -!- iang [~iang@188.29.164.243.threembb.co.uk] has quit [Quit: iang] | 07:13 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection] | 07:17 | |
| -!- hearn [~mike@cpc8-macc3-2-0-cust245.1-3.cable.virginm.net] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 07:21 | |
| -!- jtimon [~quassel@159.pool85-59-61.dynamic.orange.es] has quit [Ping timeout: 245 seconds] | 07:25 | |
| -!- zooko [~user@68.233.149.129] has joined #bitcoin-wizards | 07:26 | |
| -!- hearn [~mike@cpc8-macc3-2-0-cust245.1-3.cable.virginm.net] has joined #bitcoin-wizards | 07:29 | |
| -!- Quanttek [~quassel@2a02:8108:d00:870:a40c:c46a:a2ae:81f8] has joined #bitcoin-wizards | 07:33 | |
| -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] | 07:37 | |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards | 07:43 | |
| -!- adam3us1 [~Adium@88-105-9-250.dynamic.dsl.as9105.com] has joined #bitcoin-wizards | 07:49 | |
| -!- adam3us [~Adium@host-92-19-8-76.as13285.net] has quit [Ping timeout: 250 seconds] | 07:52 | |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Remote host closed the connection] | 07:54 | |
| -!- belcher [~belcher-s@5ec323b1.skybroadband.com] has joined #bitcoin-wizards | 07:58 | |
| -!- belcher [~belcher-s@5ec323b1.skybroadband.com] has quit [Changing host] | 07:58 | |
| -!- belcher [~belcher-s@unaffiliated/belcher] has joined #bitcoin-wizards | 07:58 | |
| -!- drawingthesun [~drawingth@106-68-221-100.dyn.iinet.net.au] has joined #bitcoin-wizards | 08:05 | |
| -!- drawingthesun [~drawingth@106-68-221-100.dyn.iinet.net.au] has quit [Ping timeout: 244 seconds] | 08:10 | |
| -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has joined #bitcoin-wizards | 08:29 | |
| -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards | 08:33 | |
| -!- jtimon [~quassel@159.pool85-59-61.dynamic.orange.es] has joined #bitcoin-wizards | 08:35 | |
| -!- iang [~iang@188.29.164.31.threembb.co.uk] has joined #bitcoin-wizards | 08:35 | |
| -!- iang [~iang@188.29.164.31.threembb.co.uk] has quit [Client Quit] | 08:36 | |
| -!- gues [~gues@cpe-66-68-54-206.austin.res.rr.com] has joined #bitcoin-wizards | 08:39 | |
| -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] | 08:42 | |
| -!- gues [~gues@cpe-66-68-54-206.austin.res.rr.com] has quit [Ping timeout: 240 seconds] | 08:44 | |
| -!- Shiftos [~shiftos@gateway/tor-sasl/shiftos] has quit [Ping timeout: 250 seconds] | 09:08 | |
| -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has quit [Ping timeout: 250 seconds] | 09:09 | |
| -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has joined #bitcoin-wizards | 09:13 | |
| -!- Shiftos [~shiftos@gateway/tor-sasl/shiftos] has joined #bitcoin-wizards | 09:13 | |
| -!- jtimon [~quassel@159.pool85-59-61.dynamic.orange.es] has quit [Ping timeout: 245 seconds] | 09:14 | |
| -!- user7779078 [user777907@gateway/vpn/mullvad/x-jcbqgarjibpcwyyf] has joined #bitcoin-wizards | 09:20 | |
| -!- hollandais [~irenacob@li629-190.members.linode.com] has quit [Remote host closed the connection] | 09:29 | |
| -!- Shiftos [~shiftos@gateway/tor-sasl/shiftos] has quit [Ping timeout: 250 seconds] | 09:32 | |
| -!- hollandais [~irenacob@li629-190.members.linode.com] has joined #bitcoin-wizards | 09:32 | |
| -!- Shiftos [~shiftos@gateway/tor-sasl/shiftos] has joined #bitcoin-wizards | 09:35 | |
| -!- adam3us1 [~Adium@88-105-9-250.dynamic.dsl.as9105.com] has quit [Ping timeout: 245 seconds] | 09:35 | |
| -!- adam3us [~Adium@88-105-25-192.dynamic.dsl.as9105.com] has joined #bitcoin-wizards | 09:35 | |
| -!- user7779078 [user777907@gateway/vpn/mullvad/x-jcbqgarjibpcwyyf] has quit [] | 09:46 | |
| -!- amarha [~EsteNuno@223.207.129.61] has joined #bitcoin-wizards | 10:05 | |
| -!- user7779078 [user777907@gateway/vpn/mullvad/x-lvabzuqmwhiirjic] has joined #bitcoin-wizards | 10:07 | |
| -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has joined #bitcoin-wizards | 10:08 | |
| -!- Profreid [~Profreitt@179.43.148.66] has quit [Quit: Profreid] | 10:11 | |
| -!- ryanxcharles [~ryanxchar@2601:9:4680:dd0:958b:8451:87eb:ce30] has quit [Ping timeout: 258 seconds] | 10:20 | |
| -!- hearn [~mike@cpc8-macc3-2-0-cust245.1-3.cable.virginm.net] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 10:20 | |
| -!- CoinMuncher [~jannes@178.132.211.90] has quit [Quit: Leaving.] | 10:25 | |
| -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has quit [Quit: iang] | 10:33 | |
| -!- Emcy_ [~MC@152.27.187.81.in-addr.arpa] has joined #bitcoin-wizards | 10:45 | |
| -!- Emcy_ [~MC@152.27.187.81.in-addr.arpa] has quit [Changing host] | 10:45 | |
| -!- Emcy_ [~MC@unaffiliated/mc1984] has joined #bitcoin-wizards | 10:45 | |
| -!- Emcy [~MC@unaffiliated/mc1984] has quit [Ping timeout: 255 seconds] | 10:47 | |
| -!- adam3us [~Adium@88-105-25-192.dynamic.dsl.as9105.com] has quit [Quit: Leaving.] | 10:48 | |
| -!- andy-logbot [~bitcoin--@wpsoftware.net] has quit [Ping timeout: 245 seconds] | 10:48 | |
| -!- SDCDev [~quassel@unaffiliated/sdcdev] has joined #bitcoin-wizards | 10:53 | |
| -!- belcher [~belcher-s@unaffiliated/belcher] has quit [Quit: Leaving] | 11:01 | |
| -!- berndj [~berndj@azna.co.za] has quit [Quit: ZNC - http://znc.in] | 11:01 | |
| -!- berndj [~berndj@azna.co.za] has joined #bitcoin-wizards | 11:02 | |
| -!- belcher [~belcher-s@5ec323b1.skybroadband.com] has joined #bitcoin-wizards | 11:06 | |
| -!- belcher [~belcher-s@5ec323b1.skybroadband.com] has quit [Changing host] | 11:06 | |
| -!- belcher [~belcher-s@unaffiliated/belcher] has joined #bitcoin-wizards | 11:06 | |
| -!- Tjopper [~Jop@dhcp-077-249-237-229.chello.nl] has quit [Read error: Connection reset by peer] | 11:21 | |
| -!- AdrianG_ is now known as AdrianG | 11:23 | |
| -!- AdrianG is now known as Guest22332 | 11:23 | |
| -!- Guest22332 [~User@107.170.31.78] has quit [Changing host] | 11:24 | |
| -!- Guest22332 [~User@unaffiliated/amphetamine] has joined #bitcoin-wizards | 11:24 | |
| -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has quit [Quit: Leaving] | 11:24 | |
| -!- NewLiberty is now known as NewLiberty-AFK | 11:24 | |
| kanzure | petertodd: "Similarly I recently had a discussion with greenaddress that indicates it'd probably make sense to also have a "get txout height" opcode to allow the creation of scripts that lock their outputs for a specific amount of time after they have been mined rather than just prevent spending until a specific point in time." | 11:24 |
| -!- Guest22332 is now known as AdrianG | 11:24 | |
| kanzure | would considering something like "check if blockhash is in blockchain" also be possible if txout height is? | 11:25 |
| kanzure | by possible i mean politically, i suppose | 11:25 |
| kanzure | nevermind, i'll just consider more edge cases on blockhash lookup opcodes | 11:27 |
| -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has joined #bitcoin-wizards | 11:39 | |
| -!- kyletorpey [~kyle@c-24-131-0-5.hsd1.va.comcast.net] has quit [Quit: Leaving.] | 11:42 | |
| -!- siraj [~siraj@adsl-68-93-64-210.dsl.hstntx.swbell.net] has joined #bitcoin-wizards | 11:46 | |
| -!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has joined #bitcoin-wizards | 11:47 | |
| -!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has quit [Changing host] | 11:47 | |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards | 11:47 | |
| andytoshi | a naive "get txout height" opcode would allow txes which can be permanently invalidated by reorgs (sans double-spending) | 11:48 |
| andytoshi | ditto for "check if blockhash in blockchain" | 11:48 |
| andytoshi | (ofc, these are very visible ... maybe people would just not trust txes spending such outputs until they were 100 confs deep or something) | 11:49 |
| tacotime | yeah, you generally don't want tx relying on on chain states | 11:49 |
| -!- orik [~orik@75.149.169.53] has joined #bitcoin-wizards | 11:49 | |
| tacotime | unless you make a consensus rule for their spending | 11:49 |
| -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [] | 11:50 | |
| tacotime | e.g. spendonlyafter COINBASE_MATURITY | 11:50 |
| andytoshi | an idea might be to require a "spendonlyafter COINBASE_MATURITY" for scriptpks which use these "reorg-unsafe opcodes" | 11:50 |
| andytoshi | or rather, every output on a transaction spending a reorg-unsafe output would need to start with a OP_SPEND_ONLY_AFTER_MATURITY | 11:51 |
| -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards | 11:52 | |
| kanzure | spendonlyafter is very different though- it's making assurances in the opposite direction | 11:53 |
| kanzure | what's wrong with "don't spend if history isn't what i thought it should be"? | 11:54 |
| kanzure | that even allows you to make spends without knowing what the final history will be | 11:54 |
| tacotime | ehm, because in that case if there is a long reorg it'll never make it back into the blockchain | 11:55 |
| tacotime | and people will lose their money | 11:55 |
| tacotime | if you reorg the bitcoin blockchain 99 blocks, you can still reincorporate every tx found in those blocks after the chain is at its new head barring double spends | 11:56 |
| kanzure | i think people lose money either way | 11:56 |
| tacotime | they lose much more money one way | 11:56 |
| kanzure | you just shift which people(?) still thinking | 11:56 |
| -!- c0rw1n [~c0rw1n@174.179-67-87.adsl-dyn.isp.belgacom.be] has quit [] | 11:56 | |
| -!- c0rw1n [~c0rw1n@174.179-67-87.adsl-dyn.isp.belgacom.be] has joined #bitcoin-wizards | 11:56 | |
| kanzure | ah, you mean if you use a "recent" blockhash | 11:57 |
| tacotime | yeah. i guess if it's older it might be less of a problem. | 11:58 |
| kanzure | within that list f 99 | 11:58 |
| kanzure | *of | 11:58 |
| -!- wyager [~wyager@cpe-24-160-153-232.satx.res.rr.com] has joined #bitcoin-wizards | 11:58 | |
| -!- kobud [wq@unaffiliated/fluffybunny] has quit [Remote host closed the connection] | 11:59 | |
| -!- lclc_bnc is now known as lclc | 12:00 | |
| -!- lclc [~lclc@bothniafur.com] has quit [Changing host] | 12:01 | |
| -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-wizards | 12:01 | |
| kanzure | spendonlyafter would still be impacted in a deep enough reorg (because blockheights can occur multiple times) (so things that happened in prior blockheights are not guaranteed to exist by spendonlyafter), whereas spendonlyafterblockhash would only be impacted once + invalidation can be conditional on an entire host of other transactions not appearing in the reorg | 12:02 |
| petertodd | andytoshi: yeah, I should specify, the "get txout height" opcode you'll want should work like the CLTV one in that it needs to be a <= comparison rather than a = comparison | 12:03 |
| kanzure | one problem is that if a service gives a user a transaction, and a reorg happens such that the transaction is invalid, giving the user another valid signed transaction means that if the reorg gets reverted that they might have two valid transactions, which is possibly deadly | 12:03 |
| petertodd | kanzure: note how I didn't say "get txout height" I said "*check* txout height" | 12:03 |
| kanzure | oh, what is the difference? | 12:03 |
| sipa | kanzure: transactions that can go from valid to invalid | 12:04 |
| petertodd | kanzure: so, if the comparison is done right a reorg can only delay mining the transaction, it can't prevent the tx from being mined at all | 12:04 |
| sipa | kanzure: something we typically don't want, as it introduces edge cases that receivers need to take into account | 12:04 |
| petertodd | kanzure: but that needs a fair bit of careful thinking to be sure the semantics are 100% right... | 12:04 |
| kanzure | sorry, i still don't understand get vs check | 12:05 |
| sipa | (like a transaction that is very close to the deadline, gets reorged through no malicious intent, and ends up being permanently unminable) | 12:05 |
| kanzure | in both cases comparison has to happen, right? | 12:05 |
| sipa | kanzure: yes, but the result of a check is only 'script is invalid'; it can't be inverted before affecting the result | 12:05 |
| petertodd | kanzure: think how the CLTV opcode itself works - it's a >= check against nLockTime, so a reorg can never result in the tx *becoming* invalid (modulo double-spends of course) | 12:06 |
| kanzure | and "get" would be what? | 12:08 |
| -!- adam3us [~Adium@88-105-25-192.dynamic.dsl.as9105.com] has joined #bitcoin-wizards | 12:08 | |
| kanzure | i suppose "unspecified behavior" hehe | 12:09 |
| sipa | kanzure: get means an opcode that fetches the height, and pushes it into the execution stack | 12:09 |
| sipa | which means you can do any type of comparison with it | 12:09 |
| petertodd | kanzure: well, GET*VERIFY as in == | 12:10 |
| petertodd | sipa: ^ | 12:10 |
| kanzure | aha, == as opposed to some other alowable manipulation, i see now | 12:10 |
| petertodd | sipa: a GET* opcode however would be push onto execution stack | 12:10 |
| kanzure | verify-or-die | 12:10 |
| petertodd | kanzure: exactly | 12:10 |
| petertodd | note how you can turn basically every opcode you could think of into a *VERIFY one, albeit at the cost of creating large scriptSigs in some situations | 12:11 |
| petertodd | Bitcoin script programming is weird :) | 12:11 |
| kanzure | a large enough spendonlyafter would give me time to double spend a second set of outputs that i sign to a user (e.g. as a second transaction for them in a reorg that will unfortunately get reverted), so that whichever future ends up being the right one, i can still spend in time (although if there's an attacker they would just not include my attempt at double spending before the blockheight lock validates) | 12:20 |
| petertodd | kanzure: ? | 12:20 |
| kanzure | i was trying to see if spendonlyafter would help my "now they have two valid transactions that might be valid in the original blockchain, but not the reorg, and the reorg might get reverted" scenario | 12:21 |
| phantomcircuit | petertodd, am i right that the PoP stuff requires that the set of audience members have a shared key? | 12:23 |
| phantomcircuit | or did i read that wrong | 12:23 |
| petertodd | kanzure: yeah, not seeing the vulnerability there | 12:23 |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards | 12:24 | |
| petertodd | phantomcircuit: it doesn't "require" a key, though symmetric encryption keys can play a part in certain specific ways of doing anti-PoP censorship | 12:24 |
| kanzure | petertodd: the vulnerability is that someone has two valid transactions from you, when you need them to only have one | 12:24 |
| phantomcircuit | petertodd, so it seems to me like without incentives you can get either censorship resistance or withholding resistance, but not both | 12:25 |
| petertodd | phantomcircuit: but note how it's fairly easy to arrange for the symmetric key to only be revealed after the data has been committed into the blockchain permanently | 12:25 |
| phantomcircuit | but you might be able to restrict the audience such that the risk of either is small enough to be a non issue | 12:25 |
| petertodd | phantomcircuit: no, consider the case of audit records, where I'm simply trying to prove to you that a given set of records isn't duplicated - e.g. I didn't double-spend you in my sidechain | 12:25 |
| kanzure | (previously with andytoshi i discussed the idea of just having a set of small single satoshi outputs sufficiently far back in history, and only ever spend those outputs for a single transaction, so that during reorgs if i hand out a different transaction they are mutually exclusive to the previous transaction i handed out) | 12:25 |
| phantomcircuit | ie any member of the audience can reveal the commitment to anybody else, but they only do so after the commitment is done | 12:26 |
| petertodd | phantomcircuit: all I have to do is show you you that the records and now committed into the bitcoin chain - there's no need for publication to be revealed immediately | 12:26 |
| petertodd | phantomcircuit: that's why I pointed out the decentralized exchange use-case of PoP as an example where you *can't* use that trick, because in most cases you can | 12:26 |
| petertodd | kanzure: ah, well, I think in general all this reorg safeness stuff is definitely a bit fragile - intentional double-spends of all kinds break it | 12:27 |
| kanzure | if the outputs you were spending originally happen to go missing, you can't know that they will always remain missing | 12:28 |
| kanzure | well, anyway, maaku's transaction serialization scheme helps a bunch https://github.com/kanzure/bitcoin-reorg-compatibility-toy/issues/2#issue-49154935 | 12:30 |
| -!- nickler_ [~nickler@185.12.46.130] has quit [Remote host closed the connection] | 12:30 | |
| -!- jps [~Jud@cpe-74-72-116-143.nyc.res.rr.com] has quit [Quit: jps] | 12:30 | |
| -!- nickler [~nickler@185.12.46.130] has joined #bitcoin-wizards | 12:30 | |
| kanzure | (actually, maaku had the idea independently, but his name for the method was better) | 12:30 |
| phantomcircuit | petertodd, audit records are strictly different than a sidechain though, a withholding attack on audit records invalidates the records, for practical purposes an equal attack could not invalidate the sidechain | 12:31 |
| -!- dulioeh [~Klaus@port-92-194-89-114.dynamic.qsc.de] has joined #bitcoin-wizards | 12:31 | |
| petertodd | phantomcircuit: you're basically arguing for a sidechain that can't be audited in any way :) | 12:31 |
| phantomcircuit | it's clear that audited records need censorship resistance and privacy, but do not need withholding resistance (merely detection) | 12:31 |
| phantomcircuit | not particularly arguing for anything at this point, but making sure i understand what you were getting at | 12:32 |
| petertodd | phantomcircuit: all I'm saying is with this "reveal after commit" trick the trusted entity is forced to reveal a consistent and globally unique set of records *at some point in time* - so for isntance if you get transferred an asset on that set of records, forever after you'll be able to show that there was a distinct and unique history where that transfer was valid and why | 12:33 |
| phantomcircuit | systems that need censorship resistance and withholding resistance however likely need incentives or some form of trusted third party (although potentially federated and only slightly trusted) | 12:33 |
| -!- adam3us [~Adium@88-105-25-192.dynamic.dsl.as9105.com] has quit [Quit: Leaving.] | 12:33 | |
| petertodd | phantomcircuit: and sure, it's "mearly detection" of withholding, but that's quite sufficient in a very large number of cases | 12:33 |
| -!- dulioeh [~Klaus@port-92-194-89-114.dynamic.qsc.de] has left #bitcoin-wizards [] | 12:34 | |
| phantomcircuit | im not sure it is though | 12:34 |
| phantomcircuit | but maybe im wrong | 12:34 |
| phantomcircuit | the issue i see is withholding of transactions which are actually invalid could cause problems | 12:34 |
| petertodd | note how censorship resistance is always no better, and very frequently worse, in merge mined instances because a minority of hashing power can effectively censor you, while in proof-of-publication you need a majority | 12:34 |
| petertodd | you're going to need to define pretty clearly what you mean by "transactions" in this case | 12:35 |
| -!- wyager [~wyager@cpe-24-160-153-232.satx.res.rr.com] has quit [Quit: wyager] | 12:35 | |
| -!- NewLiberty-AFK is now known as NewLiberty | 12:35 | |
| phantomcircuit | petertodd, anything which transfers title and requires a signature | 12:35 |
| -!- belcher_ [~belcher-s@unaffiliated/belcher] has joined #bitcoin-wizards | 12:36 | |
| petertodd | phantomcircuit: right, so arrange for your system to be able to strongly prove history of that title, no double-spends of the title, and you're good to go | 12:36 |
| petertodd | phantomcircuit: that's trivially possible with O(m log n) where m is the length of that history | 12:36 |
| -!- Dizzle [~Dizzle@pool-108-44-72-46.ronkva.east.verizon.net] has joined #bitcoin-wizards | 12:36 | |
| phantomcircuit | sure... but that doesn't help against a mallicious third party publishing linked proofs and refusing to disclose the transaction data | 12:37 |
| phantomcircuit | even if the transaction data is itself invalid, this still means the system is effectively frozen | 12:37 |
| petertodd | what do you mean by that? | 12:37 |
| -!- siraj [~siraj@adsl-68-93-64-210.dsl.hstntx.swbell.net] has quit [Remote host closed the connection] | 12:37 | |
| -!- belcher [~belcher-s@unaffiliated/belcher] has quit [Ping timeout: 272 seconds] | 12:38 | |
| -!- belcher_ is now known as belcher | 12:38 | |
| petertodd | oh wait.. do you mean publishing a claimed hash of the tx history in the bitcoin blockchain and not disclosing what that hash means? | 12:38 |
| phantomcircuit | right | 12:38 |
| petertodd | well, like I said in my paper, that's why you can't outsource proof-of-publication - why factom involves trusted third parties | 12:39 |
| phantomcircuit | or partially publishing something which could plausible be a title transfer, but which is missing some part of the record | 12:39 |
| NewLiberty | Anything would be equally plausible | 12:39 |
| petertodd | again, in uniquebits, as an example, the publication of the hash in the bitcoin blockchain is accompanied by a signature showing it's from the trusted party maintaining the records being claimed | 12:39 |
| petertodd | (note how this mistake has come up lots of times in this very channel with regard to notions of sidechains somehow being "secured" with hashes in the bitcoin blockchain) | 12:40 |
| phantomcircuit | right | 12:40 |
| phantomcircuit | ok i think all is clear | 12:40 |
| phantomcircuit | thanks | 12:40 |
| petertodd | like, my zookeyv proposal from last year was very clear on how at best you could detect the existance of a potential attacker, and being able to detect that created a censorship risk | 12:41 |
| phantomcircuit | petertodd, although if you need to contact the trusted third party to get the data, they might as well have the signatures be off chain also :P | 12:41 |
| petertodd | *no* because that gives you no way to know if the trusted party is giving you the *only* copy of the records | 12:42 |
| petertodd | the whole point of this stuff is to audit trusted third parties | 12:42 |
| petertodd | there's shades of grey in between blind trust and no trust | 12:42 |
| phantomcircuit | sure you can, gossip between peers to identify fraud from the trusted third party | 12:43 |
| phantomcircuit | but i guess that's more expensive | 12:43 |
| petertodd | without a blockchain you've got no sybil resistance... | 12:43 |
| phantomcircuit | right, but you only need 1 peer telling the truth | 12:44 |
| petertodd | gossip stuff doesn't work robustly - something I realised ages ago with my fidelity bonded banking stuff - really how I wound up coming up with proof-of-publication... | 12:44 |
| phantomcircuit | should be fairly easy to ask literally everybody if they've got a different version | 12:44 |
| petertodd | sheesh... good luck with that - big sybils against networks are cheap and easy to do compared to the type of financial rewards available fro pulling off frauds | 12:44 |
| phantomcircuit | sybil generally gets you x% of the network of peers... certainly not 100% | 12:45 |
| petertodd | this is especially important when you remember that we might be talking about a case where our "trusted" third party gets hacked - this kind of robust auditing lets you quickly detect fraud and shut things down | 12:45 |
| phantomcircuit | but yeah it's definitely unnecessarilly expensive compared to a single signature | 12:45 |
| petertodd | "typically" <- you mean when dumb 14 year olds do it | 12:46 |
| -!- jps [~Jud@172.56.34.40] has joined #bitcoin-wizards | 12:46 | |
| petertodd | the only sybil resistant p2p networks we have are darknets, and they end up looking kinda like ripple with the social trust involved | 12:46 |
| phantomcircuit | afaik the only way to get 100% is isp level mitm | 12:46 |
| petertodd | way too easy to start DoS attacking people, let alone more subtle stuff | 12:46 |
| -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards | 12:47 | |
| petertodd | ...and ISP level MITM is even pretty common | 12:47 |
| phantomcircuit | sure but isp level mitm breaks security assumptions for nearly everything discussed here :P | 12:47 |
| petertodd | remember, this is why we go and tell people proof-of-stake doesn't work - if anti-sybil tech w/o PoW was robust proof-of-stake could very well work! | 12:47 |
| phantomcircuit | it's different though | 12:48 |
| petertodd | you're dead wrong on that - with properly designed clients ISP level MITM is detected in PoW systems quite well | 12:48 |
| phantomcircuit | PoS fails with x% of the network | 12:48 |
| phantomcircuit | 1 honest peer does not win | 12:48 |
| phantomcircuit | with fraud proofs a single honest peer would be enough | 12:48 |
| petertodd | of course, we have junk like bitcoinj wallets that doesn't even save peer addresses... | 12:48 |
| phantomcircuit | petertodd, detecting a mitm for a pow system is one thing | 12:49 |
| -!- zooko [~user@68.233.149.129] has quit [Ping timeout: 240 seconds] | 12:49 | |
| phantomcircuit | but that's only effective if your wall clock time is accurate | 12:49 |
| phantomcircuit | given the prevalence of ntp | 12:49 |
| phantomcircuit | well just keep setting their clock back | 12:49 |
| -!- belcher_ [~belcher-s@unaffiliated/belcher] has joined #bitcoin-wizards | 12:50 | |
| petertodd | "with properly designed clients" - one of the things you need to do is don't let NTP set things backwards by large amounts | 12:50 |
| petertodd | fortunately the requirements on correctness are really loose | 12:50 |
| phantomcircuit | actually that's something that should probably be addressed in bitcoin at some point | 12:50 |
| phantomcircuit | it's relatively easy to detect insane clock drifts | 12:50 |
| petertodd | indeed | 12:50 |
| petertodd | also, note how much harder it is to do both a p2p sybil *and* a NTP attack at the same time - we're already coming out ahead | 12:51 |
| -!- belcher [~belcher-s@unaffiliated/belcher] has quit [Ping timeout: 244 seconds] | 12:52 | |
| gmaxwell | petertodd: although it's not any harder at all if your attack vector is you've compromised the target's ISP. | 12:53 |
| phantomcircuit | petertodd, well if you've got an isp level mitm then doing both is trivial | 12:53 |
| phantomcircuit | which is why i even mentioned it | 12:53 |
| gmaxwell | (and really thats 95% of the way to attack NTP to begin with) | 12:53 |
| petertodd | gmaxwell: like I said, we're coming out ahead because ISP level MITM is an order of magnitude harder at least than a simple P2P sybil | 12:53 |
| petertodd | gmaxwell: and PoW sybil is of course a good deal harder still... we call them 51% attacks :) | 12:53 |
| * nsh hums | 12:54 | |
| sipa | how about wifi hotspot MITM? | 12:54 |
| petertodd | sipa: when you're on a wifi hotspot, the p2p sybil is still much easier than the p2p + NTP sybil :P | 12:54 |
| petertodd | sipa: like, it's half the apt-get install commands to run for the attacker! | 12:54 |
| gmaxwell | sipa: arp soof MITM at a colo. | 12:54 |
| sipa | petertodd: right, agree there | 12:55 |
| petertodd | apt-get install pay-for-wifi-via-blockchain.info-account | 12:55 |
| phantomcircuit | gmaxwell, you cant do that at any half decent colo... but i guess there's a bunch of terrible ones | 12:56 |
| -!- siraj [~siraj@2602:304:45d4:d20:e889:9326:a5eb:bf3d] has joined #bitcoin-wizards | 12:56 | |
| -!- MoALTz [~no@user-164-126-31-182.play-internet.pl] has joined #bitcoin-wizards | 13:02 | |
| -!- jps [~Jud@172.56.34.40] has quit [Quit: jps] | 13:03 | |
| phantomcircuit | petertodd, so basically you can get censorship resistance (against anybody outside of the audience) and withholding resistance (for anybody in the audience) and anybody in the audience can disclose to anybody outside of the audience the message after the commitment is complete | 13:05 |
| phantomcircuit | neat | 13:05 |
| petertodd | phantomcircuit: yup | 13:06 |
| petertodd | phantomcircuit: and remember that with a timelock scheme, you can in principle arrange for that next message to be guaranteed to eventually be revealed | 13:07 |
| phantomcircuit | i guess the hard part is selecting the audience :P | 13:07 |
| phantomcircuit | *hand waving ensues* | 13:07 |
| phantomcircuit | petertodd, how is that? | 13:07 |
| petertodd | oh... actually, remember that the censorship resistance to publishing the next step in the system can *also* be complete against the audience of the previous step | 13:07 |
| petertodd | you don't have to reveal the keys for the next step until it comes time to tell someone about it - again, remember the title-transfer case | 13:08 |
| -!- siraj [~siraj@2602:304:45d4:d20:e889:9326:a5eb:bf3d] has quit [Remote host closed the connection] | 13:08 | |
| -!- belcher_ is now known as belcher | 13:09 | |
| petertodd | so with Trent maintaining landtitle records, Alice sells house to Bob, Trent publishes a ledger containing that sale in the blockchain, lets it confirm, then gives Bob the info required to verify that the update to the ledger was in fact the transfer he wanted, and Alice didn't sell her house to someone else | 13:09 |
| -!- Transisto [~Trans@modemcable026.188-59-74.mc.videotron.ca] has quit [] | 13:10 | |
| petertodd | Bob then sells the house to Charlie, Trent again publishes, and again reveals the update to Charlie | 13:10 |
| phantomcircuit | petertodd, right but you do need some group which has the underlying key to provide withholding resistance | 13:10 |
| phantomcircuit | ie master_key = random; key_n = H(master_key+n) | 13:11 |
| phantomcircuit | you can reveal each key_n without revealing any other key | 13:11 |
| phantomcircuit | but once someone has the underlying key you cant really change it | 13:11 |
| petertodd | *no*! again, all Trent can do is create an *invalid* ledger where they claim the house went to, say, FakeCharlie who is actually Trent, and then David, but David can detect that fraud by checking the full history himself | 13:11 |
| petertodd | *full history for that particular land title | 13:12 |
| petertodd | point is, the keys can be *per state*, and changing at each step | 13:12 |
| petertodd | again, note my more recent example where I recast that as an anti-replay algorith, with the next step being triggered by spending a specific pre-committed txout | 13:13 |
| phantomcircuit | right... your trusting trent not to withhold (and in reality he probably has no reason not to) | 13:13 |
| phantomcircuit | i was merely saying that trent can really be multiple parties | 13:13 |
| petertodd | no, I'm not trusting trent on that, I'm saying "I'm just not going to accept that the ledger is valid unless you show me it sufficiently to convince me it's valid" | 13:14 |
| petertodd | the key thing is trent is unable to maintain two different inconsistent ledgers | 13:14 |
| phantomcircuit | which is itself possibly a problem though | 13:14 |
| petertodd | why is that a problem? | 13:14 |
| phantomcircuit | since an issue with centralized systems in the past has been that they simply stop working | 13:14 |
| petertodd | when Alice sells the house to Bob, Bob just isn't going to accept the sale as valid until Bob gets proof he has the correct (portion) of the ledger showing the sale was valid | 13:15 |
| phantomcircuit | not theft or other issues... just that they decide to not do the thing anymore | 13:15 |
| phantomcircuit | (actually i think that was a bigger issuer... well at least before bitcoin it was) | 13:15 |
| petertodd | well yeah, but that's kinda unsolvable... | 13:15 |
| petertodd | if you want to solve that, put the entire thing on the blockchain | 13:15 |
| petertodd | or I really should say, "solve" that | 13:15 |
| petertodd | (again, remember all this only makes sense if we have many transactions happening in parallel, so this publication process gives us a scalability increase) | 13:16 |
| phantomcircuit | it's partially solvable by allowing the last owner to change who trent is if they can produce the proof that they have title | 13:16 |
| petertodd | (if you don't, just use colored coins) | 13:16 |
| phantomcircuit | of course they would need to select a trent2 which everybody else trusted also | 13:16 |
| petertodd | yeah, that's not a new idea at all... | 13:16 |
| phantomcircuit | or they could start with 4 trents | 13:16 |
| petertodd | I've got it in my design docs for my colored coin library | 13:17 |
| phantomcircuit | and any one of them can publish the proof | 13:17 |
| petertodd | again, 4 trents is also not a new idea at all | 13:17 |
| petertodd | you're just saying "federate it with multisig" | 13:17 |
| phantomcircuit | not saying it is :P | 13:17 |
| petertodd | remember when I talk about "trusted third party", I'm basically always equally referring to "trusted third party comprised of n-of-m signers" | 13:17 |
| petertodd | calling this stuff "federated" is just a PR gimmick - albeit a good one.. | 13:18 |
| -!- smk [~smk@unaffiliated/smk] has joined #bitcoin-wizards | 13:21 | |
| smk | How goes it, fellow adventurers | 13:21 |
| petertodd | oh, and I'll point out for completeness sake: having "trent1" say "use trent2 from now on" and also be called key rotation :) | 13:21 |
| gmaxwell | petertodd: the motivation there isn't PR, it's helping people understand better-centeralized in the same way you and I do (I think), trying to open minds to more than bimodal thinking. Words are powerful for understanding. | 13:22 |
| petertodd | gmaxwell: so, public relations :P | 13:22 |
| moa | yes it is difficult to see a rigourous definition of 'federated' being arrived at any time soon | 13:23 |
| -!- adam3us [~Adium@88-105-25-192.dynamic.dsl.as9105.com] has joined #bitcoin-wizards | 13:23 | |
| petertodd | moa: I think it's easier to understand when you say "btw the public key crypto system we're going to use for the trusted third party to sign with happens to be Bitcoin Script" | 13:23 |
| petertodd | implies multisig right off the bat... | 13:24 |
| sipa | petertodd: that already requires people to realize the "bitcoin script" can be seen a a signature system of its own, independent from bitcoin :) | 13:24 |
| sipa | (which would be so nice to have in GPG or X.509 certificates or ...) | 13:24 |
| petertodd | sipa: "it's difficult to convince peter troll to use a rigourous definition of 'easier'" | 13:26 |
| gmaxwell | I've had really mixed results with getting people to accept the idea of Script as a kind of attribute based signature system. In a general (not bitcoin heavy audience but technical) I probably get something like 66% ohh-ahhh and 33% really agressively arguing back with obsessively narrow definitions of what a _pubkey_ can be. | 13:26 |
| petertodd | sipa: I'm dangerously close to shaving a yak hurd and implementing that :P | 13:27 |
| sipa | petertodd: i'm dangerously close to having time for doing way too many things, including that - unfortunately, i have realized that i have really bad parallellism | 13:28 |
| gmaxwell | petertodd: other than threshold sitngatures it's not yet terribly useful without a number of upgrades. I certantly consider being useful for that a mandatory goal for any realistic large script upgrade. | 13:28 |
| -!- lclc is now known as lclc_bnc | 13:28 | |
| petertodd | gmaxwell: yeah, in all seriousness I think the way to approach that is to have the GPG uses treat unknown NOP's as instant fail, and think of it more as a good way to upgrade the system in the future - you'd also want to start with a MAST structure | 13:30 |
| petertodd | gmaxwell: though note how if you let it have CAT you get hash-based signature algorithms on day 1 | 13:30 |
| sipa | i think i'll implement some independent "script 2.0" library, with MAST, schnorr sigs, efficient multisig, delegation and a few more things | 13:31 |
| sipa | and see how large that grows | 13:31 |
| petertodd | yup | 13:31 |
| moa | sipa do it please | 13:31 |
| sipa | it could be experimented with in things that don't have the horrible consistency requirements bitcoin has | 13:32 |
| petertodd | just make it have GPG mode where unknown upgradable NOPs die instantly and a converse soft-forkable mode where they don't fail | 13:32 |
| sipa | and if found useful enough, *forked* to implement a bitcoin script 2.0 | 13:32 |
| petertodd | also, MAST is interesting as you could have it *conceptually* treat all opcodes as *VERIFY's and then make them return stuff on the stack be purely a serialization space compression optimization | 13:33 |
| -!- amarha [~EsteNuno@223.207.129.61] has quit [Read error: Connection reset by peer] | 13:33 | |
| sipa | petertodd: yup | 13:33 |
| Alanius | what is MAST? | 13:33 |
| petertodd | technically you can do that in Bitcoin script too, but holy shit would it be ugly :) | 13:33 |
| sipa | Alanius: merkleized abstract syntax tree | 13:33 |
| sipa | Alanius: encode the expression to evaluate as a tree, where each node has a hash computed from its function id and its children | 13:34 |
| sipa | Alanius: and then you can choose to not disclose unevaluated branches | 13:34 |
| -!- butters [~butters@dslb-178-008-078-133.178.008.pools.vodafone-ip.de] has joined #bitcoin-wizards | 13:39 | |
| -!- vmatekole [~vmatekole@p5DC473BE.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] | 13:44 | |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection] | 13:51 | |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards | 13:52 | |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Ping timeout: 245 seconds] | 13:56 | |
| -!- hashtag_ [~hashtag@cpe-98-157-219-44.ma.res.rr.com] has quit [Ping timeout: 252 seconds] | 14:10 | |
| phantomcircuit | i wonder how close power efficiency for aes-ni is compared to a gpu/fpga/asic | 14:11 |
| gmaxwell | AES on a convention cpu is pretty darn efficient, if you don't care about possible cache-related timing sidechannels. | 14:12 |
| gmaxwell | er conventional* | 14:12 |
| phantomcircuit | i do not for this application | 14:12 |
| phantomcircuit | (and no it's not pow...) | 14:12 |
| -!- waxwing [waxwing@gateway/vpn/mullvad/x-xpvatopenkfairhk] has quit [Ping timeout: 245 seconds] | 14:14 | |
| -!- ryanxcharles [~ryanxchar@2601:9:4680:dd0:70b4:ef77:81f:8211] has joined #bitcoin-wizards | 14:15 | |
| -!- adam3us [~Adium@88-105-25-192.dynamic.dsl.as9105.com] has quit [Quit: Leaving.] | 14:20 | |
| -!- waxwing [~waxwing@62.205.214.125] has joined #bitcoin-wizards | 14:27 | |
| -!- AnoAnon [~AnoAnon@197.37.57.96] has joined #bitcoin-wizards | 14:29 | |
| -!- AnoAnon [~AnoAnon@197.37.57.96] has quit [Read error: Connection reset by peer] | 14:30 | |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Remote host closed the connection] | 14:30 | |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards | 14:30 | |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Ping timeout: 250 seconds] | 14:35 | |
| -!- jps [~Jud@172.56.22.91] has joined #bitcoin-wizards | 14:46 | |
| -!- jps [~Jud@172.56.22.91] has quit [Client Quit] | 14:47 | |
| -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has quit [Quit: Leaving] | 15:00 | |
| -!- devrandom [~devrandom@gateway/tor-sasl/niftyzero1] has quit [Quit: leaving] | 15:01 | |
| -!- atgreen [~user@CPE687f74122463-CM84948c2e0610.cpe.net.cable.rogers.com] has quit [Ping timeout: 252 seconds] | 15:04 | |
| -!- Guest22056 [~omni@ip68-4-111-228.oc.oc.cox.net] has quit [] | 15:05 | |
| -!- fanquake [~anonymous@unaffiliated/fanquake] has joined #bitcoin-wizards | 15:06 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 15:06 | |
| -!- omni [~omni@ip68-4-111-228.oc.oc.cox.net] has joined #bitcoin-wizards | 15:08 | |
| -!- omni is now known as Guest44359 | 15:08 | |
| -!- maraoz [~maraoz@181.29.97.171] has quit [Ping timeout: 240 seconds] | 15:12 | |
| -!- hashtag_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards | 15:22 | |
| -!- user7779078 [user777907@gateway/vpn/mullvad/x-lvabzuqmwhiirjic] has quit [Remote host closed the connection] | 15:27 | |
| -!- HaltingState [~HaltingSt@unaffiliated/haltingstate] has joined #bitcoin-wizards | 15:31 | |
| -!- Shiftos [~shiftos@gateway/tor-sasl/shiftos] has quit [Remote host closed the connection] | 15:31 | |
| rusty | maaku: thanks, applying your pull requests now. Will have to create ascii art explaining MMR tree, once I understand it :) | 15:35 |
| -!- thrasher` [~thrasher@27-33-27-140.static.tpgi.com.au] has joined #bitcoin-wizards | 15:38 | |
| -!- gues [~gues@172-7-226-202.lightspeed.hstntx.sbcglobal.net] has joined #bitcoin-wizards | 15:49 | |
| -!- bosma [~bosma@S01067cb21bda6531.vc.shawcable.net] has quit [Quit: Leaving] | 15:51 | |
| -!- fanquake [~anonymous@unaffiliated/fanquake] has quit [Quit: fanquake] | 15:52 | |
| -!- gues [~gues@172-7-226-202.lightspeed.hstntx.sbcglobal.net] has quit [Ping timeout: 244 seconds] | 15:54 | |
| -!- gues [gues@gateway/vpn/mullvad/x-wnedwdqycyjheyqc] has joined #bitcoin-wizards | 15:56 | |
| -!- orik [~orik@75.149.169.53] has quit [Ping timeout: 272 seconds] | 15:56 | |
| -!- Shiftos [~shiftos@gateway/tor-sasl/shiftos] has joined #bitcoin-wizards | 16:00 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] | 16:02 | |
| -!- epscy [~epscy@176.126.241.239] has joined #bitcoin-wizards | 16:15 | |
| -!- zooko [~user@68.233.149.129] has joined #bitcoin-wizards | 16:17 | |
| -!- gues [gues@gateway/vpn/mullvad/x-wnedwdqycyjheyqc] has quit [Ping timeout: 245 seconds] | 16:17 | |
| -!- gues [gues@gateway/vpn/mullvad/x-lhvdnuaclhttcdlt] has joined #bitcoin-wizards | 16:19 | |
| -!- MoALTz_ [~no@user-164-126-31-182.play-internet.pl] has joined #bitcoin-wizards | 16:20 | |
| -!- MoALTz [~no@user-164-126-31-182.play-internet.pl] has quit [Ping timeout: 244 seconds] | 16:23 | |
| -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [] | 16:25 | |
| -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards | 16:27 | |
| -!- siervo [uid49244@gateway/web/irccloud.com/x-stdrwnesmlxmqyjf] has joined #bitcoin-wizards | 16:35 | |
| -!- Cory [~Cory@unaffiliated/cory] has quit [] | 16:36 | |
| -!- Cory [~Cory@unaffiliated/cory] has joined #bitcoin-wizards | 16:55 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 16:56 | |
| -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has joined #bitcoin-wizards | 16:58 | |
| rusty | maaku: your depth calculation isnt' correct. I implemented mmr trees and actually did traverse to get depth (thanks to petertodd's excellent documentation). | 17:00 |
| -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has quit [Client Quit] | 17:03 | |
| -!- Dizzle [~Dizzle@pool-108-44-72-46.ronkva.east.verizon.net] has quit [Quit: Leaving...] | 17:04 | |
| -!- moa [~kiwigb@opentransactions/dev/moa] has quit [Quit: Leaving.] | 17:05 | |
| -!- afk11 [~afk11@dsl-088-099.cust.imagine.ie] has joined #bitcoin-wizards | 17:12 | |
| -!- statdude [~statdude@c-67-172-240-196.hsd1.ut.comcast.net] has joined #bitcoin-wizards | 17:15 | |
| -!- statdude [~statdude@c-67-172-240-196.hsd1.ut.comcast.net] has quit [Client Quit] | 17:15 | |
| -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 252 seconds] | 17:19 | |
| -!- atgreen [~user@CPE687f74122463-CM84948c2e0610.cpe.net.cable.rogers.com] has joined #bitcoin-wizards | 17:20 | |
| -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-wizards | 17:20 | |
| -!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has joined #bitcoin-wizards | 17:23 | |
| -!- afk11 [~afk11@dsl-088-099.cust.imagine.ie] has quit [Ping timeout: 245 seconds] | 17:26 | |
| rusty | maaku: ... or my tree implementation is buggy... | 17:34 |
| -!- afk11 [~afk11@dsl-088-099.cust.imagine.ie] has joined #bitcoin-wizards | 17:40 | |
| -!- faraka [835eba0a@gateway/web/freenode/ip.131.94.186.10] has joined #bitcoin-wizards | 17:40 | |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards | 17:43 | |
| faraka | so basically proof of existence is putting a hash in to 40 byte space? | 17:43 |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Remote host closed the connection] | 17:45 | |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards | 17:45 | |
| petertodd | rusty: is that repo up on github? | 17:51 |
| rusty | petertodd: I'll push now, one sec. | 17:51 |
| petertodd | faraka: yup, I have that as a demo of how to use my python-bitcoinlib library: https://github.com/petertodd/python-bitcoinlib/blob/master/examples/timestamp-op-ret.py | 17:52 |
| petertodd | faraka: though proof-of-existance does have a nice privacy benefit as they timestamp stuff using a proof of funds shared among all users of the service | 17:52 |
| petertodd | rusty: thanks, url? | 17:52 |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Remote host closed the connection] | 17:53 | |
| faraka | thanks petertodd | 17:53 |
| faraka | hey Peter, in your opinion what technological aspect is missing in the cryptocurrency space? | 17:53 |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards | 17:53 | |
| rusty | petertodd: https://github.com/rustyrussell/rusty-junkcode/blob/master/test-trees.c | 17:54 |
| petertodd | faraka: scalability, although that's more of a political question in some ways | 17:54 |
| petertodd | rusty: oh cool! | 17:54 |
| faraka | what do you think about codius peter? | 17:55 |
| petertodd | faraka: that they say "decentralized apps" rather than "distributed apps" on their front page isn't a good sign... cool and all, but codius is a trusted third party | 17:56 |
| petertodd | faraka: also re smart contracts: https://twitter.com/petertoddbtc/status/540910541360099328 | 17:56 |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Ping timeout: 250 seconds] | 17:58 | |
| petertodd | rusty: re: mmr's, what are you trying to optimize for in your usecase? (heck, what exactly is your usecase?) | 18:03 |
| rusty | petertodd: heh.. | 18:03 |
| rusty | petertodd: OK, so I'm writing a compact SPV simulator for a blockchain. | 18:03 |
| petertodd | right | 18:04 |
| rusty | petertodd: assuming that all prevs are merkled treed into each block, what tree topology is optimal? | 18:04 |
| petertodd | rusty: yeah, the persistently reoccuring proposal of making a non-linearly linked block headers chain :) | 18:04 |
| rusty | petertodd: exactly... I'm trying to actually get some data. | 18:05 |
| -!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 18:05 | |
| petertodd | rusty: do you have a clear set of things that you want to be able to prove with your data structure? | 18:05 |
| rusty | petertodd: well,so far, I've discovered that topology definitely matters :) | 18:05 |
| petertodd | rusty: lol | 18:06 |
| rusty | petertodd: and that the naive approach of optimizing for minimal # backward skips, then calculating the proof, is about 20% worse than optimizing the backward skips for size of proof directly. | 18:07 |
| petertodd | rusty: making block headers link to H(entire previous blockchain serialized in random order) is one topology you may want to avoid | 18:07 |
| -!- faraka [835eba0a@gateway/web/freenode/ip.131.94.186.10] has quit [Ping timeout: 246 seconds] | 18:07 | |
| petertodd | rusty: as in, skiplist-type organizations? | 18:07 |
| gmaxwell | petertodd: he's constructing log scaling evidence of work proofs for block/txn membership. | 18:08 |
| petertodd | gmaxwell: ah, well that's quite different | 18:08 |
| rusty | petertodd: well, each block contains a binary merkle tree (or variant: binary tree with internal nodes). But they are traversed as a skiplist, with skips up to (blockhash / difficulty). | 18:08 |
| -!- Sub|zzz is now known as SubCreative | 18:09 | |
| petertodd | rusty: right - I say that because you might find there are other use-cases for this with quite different requirements, e.g. efficient fraud proofs, and especially, bounded-size fraud proofs | 18:09 |
| rusty | petertodd: yeah, so I am mainly measuring # hashes to prove back to genesis, though my cmdline can specify a different terminator. | 18:11 |
| rusty | petertodd: which is the other obvious case I could think of. | 18:11 |
| -!- aburan28 [~ubuntu@pool-96-243-78-142.bnghny.east.verizon.net] has joined #bitcoin-wizards | 18:11 | |
| -!- belcher [~belcher-s@unaffiliated/belcher] has quit [Quit: Leaving] | 18:12 | |
| rusty | maaku: how embarrassing, you relied on my rfc6962 code, which was buggy.... | 18:13 |
| petertodd | rusty: by "# hashes to prove back to genesis" you mean in the context of proving some type of total work evidence right? | 18:14 |
| petertodd | rusty: obviously we could solve *just* that problem with a little less work :P | 18:14 |
| rusty | petertodd: yeah, as suggested (for example) for sidechain proofs. | 18:14 |
| rusty | petertodd: nice pun :) | 18:14 |
| petertodd | rusty: I'd like to say I was smart enough for that to be delibrate, but alas... | 18:15 |
| petertodd | rusty: seems to me that sidechain total work proofs should be essentially equal to the problem of a SPV node syncing to the network too | 18:15 |
| gmaxwell | Yep. Thats one application of the compact proofs. | 18:16 |
| rusty | petertodd: related, though the SPV node may not need proof to the genesis. Though it's pretty cheap. | 18:16 |
| petertodd | you know, one way to avoid the need to prove back to the genesis would be to make the backward hashed links be mutated by the genesis block in some way, e.g. replace SHA2 with a HMAC-SHA2 keyed by the genesis | 18:17 |
| petertodd | not necessarily relevant here, but interesting to think about | 18:17 |
| sipa | petertodd: that's no different from just having every block header commit to genesis | 18:17 |
| -!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has joined #bitcoin-wizards | 18:17 | |
| sipa | petertodd: as one of its links | 18:17 |
| petertodd | sipa: yes I know | 18:18 |
| sipa | if that's useful, then yes :) | 18:18 |
| petertodd | sipa: it could be a smaller proof in some cases | 18:18 |
| -!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has quit [Client Quit] | 18:19 | |
| petertodd | rusty, sipa: I forget, is this going to include some kind of total work summing in the tree itself? | 18:19 |
| rusty | petertodd: that was the suggestion, though I'm ignoring it for my comparison work. | 18:20 |
| petertodd | rusty: one consideration there might be the shape of hashrate growth - be interesting if non-stready states change it | 18:21 |
| gmaxwell | petertodd: hashrate growth results in much smaller proofs. | 18:22 |
| gmaxwell | (my initial implementation of a simulator I thought was broken because the proofs were so small when testing against bitcoin data.) | 18:22 |
| petertodd | gmaxwell: sure, but what about high variable? particularly maliciously constructed highly variable cases | 18:23 |
| gmaxwell | petertodd: if you grind away long backlinks you can force it to linear scaling at tremendous computational cost. | 18:24 |
| gmaxwell | (e.g. assuming you were a majority hashpower attacker) | 18:25 |
| rusty | gmaxwell: not really, since replacing 1 in 16 blocks would have significant effect. | 18:26 |
| gmaxwell | rusty: the computational cost to replace is very large, so you'll be beat in the race unless you have a very large fraction of the networks hashpower. | 18:27 |
| rusty | gmaxwell: yeah, it's possible in a scenario where you can variably acquire > 50% hash power. | 18:28 |
| gmaxwell | if you're only removing just some one in n thats just a constant factor. | 18:28 |
| gmaxwell | rusty: yes. | 18:28 |
| rusty | gmaxwell: but it's hard to see the point of doing so. It's not as directly profitable as other attacks. | 18:28 |
| gmaxwell | sure sure, one should strive for byzantine security though; when possible. | 18:29 |
| rusty | gmaxwell: Actually, the structure is extremely sensitive to luck. If you wanted to just be a dick, you could attack 1 block in a million or so. OTOH, you could favour an extremely lucky block that was otherwise due to be orphaned. | 18:30 |
| petertodd | so when we say replacement here, we mean construct a valid-looking block header chain tip that fraudulently commits to a block way back in the chain that prior tips didn't commit to, correct? | 18:32 |
| -!- Dr-G3 [~Dr-G@gateway/tor-sasl/dr-g] has joined #bitcoin-wizards | 18:33 | |
| rusty | gmaxwell: but even such an attack just returns to the mean, and it's the difference between eg. 14 steps to do 8M blocks and ~100. | 18:33 |
| gmaxwell | petertodd: no. thats not interesting. (or at least it doesn't result in violating the expected work) | 18:33 |
| rusty | petertodd: no, we're referring to actually racing the blockchain to eliminate the "lucky" blocks which are needed for skipping. | 18:33 |
| rusty | s/eliminate/orphan/ | 18:34 |
| gmaxwell | petertodd: by replacement we're talking about causing proofs to be larger by selectively orphaning lucky blocks that are permitted to backlink long distances. | 18:34 |
| petertodd | ok | 18:34 |
| gmaxwell | (orphaning or withholding) | 18:34 |
| -!- Dr-G2 [~Dr-G@gateway/tor-sasl/dr-g] has quit [Ping timeout: 250 seconds] | 18:36 | |
| gmaxwell | rusty: when thinking about this before I did come up with a more complex structure that suppressed it, basicaly using the next blocks to determine the hash of this block for the purpose of backlink validity bar, with different blocks controlling different subsets. But it was more complex to reason about and I couldn't come up with a reason that an improvement was really needed. (and of course it | 18:36 |
| gmaxwell | doesn't help against a true super majority that can just compute multiple blocks) | 18:37 |
| gmaxwell | (and it made the proofs larger) | 18:37 |
| rusty | Anyway, thanks maaku, petertodd: mmr is the new winner for topology. | 18:37 |
| gmaxwell | That was in fact the topology I'd assumed was in use. (I was really confused by maaku's and your discussion the other day) | 18:38 |
| rusty | gmaxwell: interesting... yes, I can't quite see why it would win very much. | 18:38 |
| rusty | gmaxwell: heh, but I'd never heard of it! | 18:38 |
| petertodd | rusty: which direction does your MMR implementation hash the peaks? remember that it can result in much higher variability of path length depending on how you implement it | 18:39 |
| rusty | petertodd: block 0 ends up leftmost in leftmost (and largest) mountain. | 18:40 |
| rusty | petertodd: peaks are connected using the rfc6962 topology. | 18:40 |
| petertodd | rusty: no, I don't mean that, I mean how you link together those peaks | 18:40 |
| rusty | ^^ | 18:41 |
| petertodd | rusty: ok, that doesn't sound like what I implemented - if I understand rfc6962 correctly it basically turns any merkle tree it hashes into a power of two, with the unused parts marked specially | 18:42 |
| petertodd | rusty: for instance, you see that you could implement it by hashing the peaks as a linear linked list right? | 18:43 |
| rusty | petertodd: you could, but that'd suck, right? | 18:43 |
| rusty | petertodd: (for minimizing proof lengths, I mean) | 18:43 |
| rusty | petertodd: rfc6962 (well, as I implemented it) just puts P on the left and N-P on the right, where P is the power of 2 which is < N. | 18:44 |
| petertodd | rusty: that it would :) the OpenTimestamps implementation basically repeats a merkle tree on top, where the parts that don't fit into the power of two are just bumped to the "next level" - they aren't hashed twice like satoshi's implementation does | 18:44 |
| rusty | petertodd: sounds similar. | 18:45 |
| petertodd | rusty: ok, I think then you did implement my algorithm, and that's either different from rfc6962, or I misunderstood the latter | 18:45 |
| rusty | petertodd: the effect, here, is that recent block hashes are of lesser depth, which helps CSPV proofs. | 18:46 |
| rusty | petertodd: I blame maaku, he called what I implemented rfc6962 :) | 18:46 |
| petertodd | rusty: <rereading> oh, yeah, I think I misunderstood rfc6962 - ok, so it implements what my MMR algorithm does | 18:47 |
| maaku | petertodd: i think you misunderstood the latter | 18:47 |
| rusty | maaku: hi! | 18:47 |
| maaku | my reading of rfc6962 is what your and my MMR implementation does | 18:47 |
| maaku | (for the mountain bagging step) | 18:48 |
| maaku | it lacks bitcoind's repeat-the-hash step, and so creates unbalanced trees | 18:49 |
| maaku | hi rusty | 18:49 |
| rusty | maaku: patches applied, and mmr calc rewritten. Yours wasn't quite right, but I couldn't figure out how. | 18:50 |
| rusty | maaku: mine is ulgier, though :( | 18:50 |
| petertodd | maaku: yeah, as far as I can tell RFC6962 == MMR, except the latter doesn't have the clear domain separation - not needed for timestamping | 18:50 |
| maaku | petertodd: ? to be clear I don't think RFC6962 is anything like an MMR. but the "construct a Merkle tree of the peak root hashes" step is rfc6962 | 18:52 |
| maaku | at least as I interpreted it from your description, and implemented | 18:52 |
| petertodd | maaku: see, I think the problem here is RFC6962 has a "top-down" description of how the tree is built, but the end result is identical in structure | 18:53 |
| maaku | petertodd: it results in different (and better) trees in the implementation I did | 18:54 |
| maaku | haven't looked at rusty's new implemention yet | 18:54 |
| maaku | rusty: pretty sure your new implementation is wrong | 18:55 |
| rusty | maaku: check back a few commits, I actually generated the tree to test your depth formula. | 18:55 |
| rusty | maaku: probably :) | 18:55 |
| petertodd | so from the RFC "For n > 1, let k be the largest power of two smaller than n (i.e., k < n <= 2k). The Merkle Tree Hash of an n-element list D[n] is then defined recursively as | 18:56 |
| petertodd | MTH(D[n]) = SHA-256(0x01 || MTH(D[0:k]) || MTH(D[k:n]))," | 18:56 |
| petertodd | basically that's dividing the items in the list into "Biggest power of two mountain" and "everything else recursively" | 18:56 |
| petertodd | that's exactly what MMR is doing | 18:56 |
| petertodd | now you can have MMR work the opposite way, where tip->peak distance is smallest for most recently mountains by reversing the order in which peaks are hashed together, but at least the other order is identical | 18:57 |
| maaku | rusty: nevermind you changed the peak ordering, so this should be correct | 19:01 |
| maaku | rusty: it generated different numbers though? | 19:01 |
| rusty | maaku: yeah... now I'm looking at the trees to figure out what the difference in topologies actually is... | 19:02 |
| rusty | maaku: see 90f4f445ba7a56e5c214987de16d5dbd0e46c92a, and change #if 0 to #if 1,and you'll see your implementation trips an assert. | 19:03 |
| -!- GAit [~lnahum@enki.greenaddressit.p3.tiktalik.io] has quit [Remote host closed the connection] | 19:03 | |
| petertodd | "2.1.2. Merkle Consistency Proofs" works the same way too: the subproofs are basically just saying "show all the power of two mountains in the first tree are present in the second to prove the append-only property" | 19:05 |
| -!- coiner [~linker@1.54.73.86] has quit [Read error: Connection reset by peer] | 19:08 | |
| rusty | well, our implementations of the two are definitely different. | 19:08 |
| -!- coiner [~linker@1.54.73.86] has joined #bitcoin-wizards | 19:08 | |
| rusty | petertodd: 7 element mmr tree: | 19:08 |
| rusty | /\ | 19:08 |
| rusty | / 6 | 19:08 |
| rusty | /\ | 19:08 |
| rusty | / \ | 19:08 |
| rusty | / \ | 19:08 |
| rusty | / \ | 19:08 |
| rusty | /\ /\ | 19:08 |
| rusty | / \ 4 5 | 19:08 |
| rusty | /\ /\ | 19:08 |
| rusty | 0 1 2 3 | 19:08 |
| rusty | 7 element rfc6962: | 19:09 |
| rusty | /\ | 19:09 |
| rusty | / \ | 19:09 |
| rusty | / \ | 19:09 |
| rusty | / \ | 19:09 |
| rusty | /\ /\ | 19:09 |
| rusty | / \ / \ | 19:09 |
| rusty | /\ /\ /\ \ | 19:09 |
| rusty | 0 1 2 3 4 5 6 | 19:09 |
| petertodd | exactly! the only difference is the order in which peaks are hashed together | 19:09 |
| petertodd | MMR makes it explicit that you have a choice | 19:09 |
| petertodd | in fact, if you look at my original writeup you'll see it's in RFC6962 order, and identical: https://github.com/opentimestamps/opentimestamps-server/blob/348ca0b0ee3f9931a5d9ddd7951214aab52a383e/doc/merkle-mountain-range.md | 19:10 |
| rusty | petertodd: OK, well, MMR-with-rfc6962-for-bagging turns out to be excellent for SPV proofs. Thanks maaku. | 19:10 |
| petertodd | IIRC I did it the other way around in OpenTimestamps itself because in timestamping it kept proof length short on average for recent timestamps, which was what I needed | 19:11 |
| petertodd | and I published that Oc 21 2012, a good 7 months before RFC6962 :P | 19:12 |
| petertodd | rusty: the funny thing is another way to describe it is MMR with MMR on top recursively until you're done hashing everything :P | 19:13 |
| petertodd | in any case, so the problem with "recent-is-shortest MMR" is there isn't an obvious way to prove the index # of an entry based purely on the path to the tip; some domain separation may help there | 19:19 |
| petertodd | hmm, and actually, yeah, that's true in both cases, so you may want to make the second "hash all the peaks" part include something in the hash to make it distinct from the power of two tree hashing phase | 19:20 |
| -!- Quanttek [~quassel@2a02:8108:d00:870:a40c:c46a:a2ae:81f8] has quit [Remote host closed the connection] | 19:24 | |
| -!- user7779078 [~user77790@193.138.219.233] has joined #bitcoin-wizards | 19:26 | |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards | 19:32 | |
| -!- afk11 [~afk11@dsl-088-099.cust.imagine.ie] has quit [Ping timeout: 245 seconds] | 19:34 | |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Ping timeout: 250 seconds] | 19:36 | |
| -!- siervo [uid49244@gateway/web/irccloud.com/x-stdrwnesmlxmqyjf] has quit [] | 19:43 | |
| -!- user7779078 [~user77790@193.138.219.233] has quit [Remote host closed the connection] | 19:45 | |
| maaku | petertodd: path to tip plus tree size is sufficient | 19:46 |
| maaku | that's what we're doing in the code | 19:46 |
| maaku | it's not a succinct one-liner, but it's doable | 19:46 |
| maaku | well we go the other way, but it's transoformable to operate in that direction | 19:47 |
| maaku | rusty: btw just pulled and it doesn't compile | 19:50 |
| -!- wiz [~sid1@core.nsa.network] has joined #bitcoin-wizards | 19:51 | |
| maaku | you in the middle of something? | 19:51 |
| rusty | maaku: yep... fixing now :) | 19:51 |
| maaku | rusty: so MMR with linear access to the peaks might even work better for SPV proofs | 19:52 |
| maaku | it'd be interesting to try that | 19:52 |
| rusty | maaku: done... yeah, I'm trying a cache of the 32 "luckiest" blocks at the moment. | 19:53 |
| -!- devrandom [~devrandom@gateway/tor-sasl/niftyzero1] has joined #bitcoin-wizards | 19:53 | |
| rusty | maaku: linear access? | 19:53 |
| maaku | like you were doing for the batch trees | 19:53 |
| maaku | take right branch to access peak, take left branch to go to next peak | 19:54 |
| maaku | so the peaks end up in a sequence instead of a rfc6962 tree | 19:54 |
| maaku | * take left branch to access a decision branch for the next peak | 19:56 |
| rusty | maaku: my *gut* feeling is that it will punish long jumps too much, but I could be wrong. | 19:57 |
| maaku | rusty: right, but you take a long jump once, and short jumps many times. | 19:58 |
| maaku | the change is simple "rfc6962_proof_len(mtns, peaknum)" -> "mtns - peaknum - 1" | 19:58 |
| -!- siraj [~siraj@adsl-68-93-67-122.dsl.hstntx.swbell.net] has joined #bitcoin-wizards | 19:58 | |
| rusty | maaku: not in practice: a CSPV proof is biassed towards long jumps. But yeah, one second.. | 19:59 |
| -!- siraj [~siraj@adsl-68-93-67-122.dsl.hstntx.swbell.net] has quit [Remote host closed the connection] | 19:59 | |
| maaku | rusty: are you doing some sort of dynamic programming to find the shortest paths? | 20:03 |
| rusty | maaku: yeah, see the inner loop (which uses j). | 20:04 |
| rusty | maaku: I think it's mtns - peaknum, with only a -1 for peaknum == 0. | 20:04 |
| maaku | rusty: right you always need one branch. i think you mean mtns == 0 | 20:06 |
| maaku | *mtns == 1 | 20:07 |
| rusty | maaku: no, from != 0 so mtns != 0. | 20:07 |
| rusty | maaku: the 0th peak is special, because it's the same depth as peak 1. | 20:07 |
| rusty | ie. everything else is on a right branch, it's on a left branch. | 20:08 |
| maaku | rusty: shouldn't be. peak 0 is at depth 1 (0-based), peak 1 is at depth 2 | 20:08 |
| rusty | maaku: ah, how are we counting peaks... lemme check the code again... | 20:09 |
| maaku | gah yeah we're assuming different ordering | 20:09 |
| maaku | i see what you mean. the last peak is -1 | 20:09 |
| -!- Burrito [~Burrito@unaffiliated/burrito] has quit [Ping timeout: 265 seconds] | 20:11 | |
| -!- christo [~christo@eth59-167-133-100.static.internode.on.net] has joined #bitcoin-wizards | 20:12 | |
| rusty | maaku: slightly worse than mmr+rfc. | 20:28 |
| rusty | prooflen-mmr: proof hashes 108-2048(736.812+/-4.6e+02) | 20:28 |
| rusty | prooflen-mmr-linear: proof hashes 130-1956(757.188+/-4.4e+02) | 20:28 |
| -!- beamlaser [49cc4c7f@gateway/web/freenode/ip.73.204.76.127] has joined #bitcoin-wizards | 20:30 | |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 265 seconds] | 20:31 | |
| beamlaser | does anyone know of multisig threshold implementation in java? | 20:32 |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards | 20:33 | |
| -!- aburan28 [~ubuntu@pool-96-243-78-142.bnghny.east.verizon.net] has quit [Ping timeout: 265 seconds] | 20:42 | |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards | 20:42 | |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Ping timeout: 250 seconds] | 20:47 | |
| -!- coiner [~linker@1.54.73.86] has quit [Ping timeout: 255 seconds] | 20:51 | |
| -!- beamlaser [49cc4c7f@gateway/web/freenode/ip.73.204.76.127] has quit [Ping timeout: 246 seconds] | 20:53 | |
| rusty | maaku: OK, with 32 or 64 luckiest entries in a cache, I've reduced it from 740 hashes to 700. I think using a huffman tree might get that down a bit more, but we seem to be close to the minimum size for 8M blocks. | 20:57 |
| rusty | Still, a factor of 12000 times is nothing to sneeze at. | 20:59 |
| -!- Transisto [~Trans@modemcable017.87-131-66.mc.videotron.ca] has joined #bitcoin-wizards | 21:08 | |
| -!- siraj [~siraj@adsl-68-93-67-122.dsl.hstntx.swbell.net] has joined #bitcoin-wizards | 21:17 | |
| -!- NewLiberty [~NewLibert@2602:304:cff8:1580:a9dd:bf2d:7ebb:12ec] has quit [Ping timeout: 258 seconds] | 21:23 | |
| -!- christo [~christo@eth59-167-133-100.static.internode.on.net] has quit [Remote host closed the connection] | 21:26 | |
| -!- MoALTz [~no@user-164-126-31-182.play-internet.pl] has joined #bitcoin-wizards | 21:41 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] | 21:42 | |
| -!- NewLiberty [~NewLibert@2602:304:cff8:1580:5961:441d:67c6:ffc2] has joined #bitcoin-wizards | 21:44 | |
| -!- MoALTz_ [~no@user-164-126-31-182.play-internet.pl] has quit [Ping timeout: 256 seconds] | 21:44 | |
| -!- Dr-G3 [~Dr-G@gateway/tor-sasl/dr-g] has quit [Ping timeout: 250 seconds] | 21:47 | |
| -!- Dr-G3 [~Dr-G@gateway/tor-sasl/dr-g] has joined #bitcoin-wizards | 21:52 | |
| -!- Guest89604 [~Pan0ram1x@095-096-084-122.static.chello.nl] has quit [Ping timeout: 245 seconds] | 21:55 | |
| -!- coiner [~linker@113.161.87.238] has joined #bitcoin-wizards | 21:58 | |
| -!- Pan0ram1x [~Pan0ram1x@095-096-084-122.static.chello.nl] has joined #bitcoin-wizards | 22:01 | |
| -!- Pan0ram1x is now known as Guest2745 | 22:02 | |
| -!- ryanxcharles [~ryanxchar@2601:9:4680:dd0:70b4:ef77:81f:8211] has quit [Ping timeout: 258 seconds] | 22:15 | |
| -!- ryanxcharles [~ryanxchar@2601:9:4680:dd0:70b4:ef77:81f:8211] has joined #bitcoin-wizards | 22:19 | |
| -!- koshii [~0@c-68-58-151-30.hsd1.in.comcast.net] has quit [Quit: leaving] | 22:32 | |
| -!- user7779078 [~user77790@c-73-1-104-107.hsd1.fl.comcast.net] has joined #bitcoin-wizards | 22:33 | |
| -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 244 seconds] | 22:39 | |
| -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-wizards | 22:40 | |
| -!- Dizzle [~Dizzle@pool-108-44-72-46.ronkva.east.verizon.net] has joined #bitcoin-wizards | 22:47 | |
| -!- koshii [~0@c-68-58-151-30.hsd1.in.comcast.net] has joined #bitcoin-wizards | 22:52 | |
| -!- aburan28 [~ubuntu@107.107.60.166] has joined #bitcoin-wizards | 22:58 | |
| -!- jtimon [~quassel@159.pool85-59-61.dynamic.orange.es] has joined #bitcoin-wizards | 23:05 | |
| -!- user7779078 [~user77790@c-73-1-104-107.hsd1.fl.comcast.net] has quit [Ping timeout: 265 seconds] | 23:24 | |
| -!- adam3us [~Adium@172.56.13.107] has joined #bitcoin-wizards | 23:33 | |
| -!- Dizzle [~Dizzle@pool-108-44-72-46.ronkva.east.verizon.net] has quit [Quit: Leaving...] | 23:38 | |
| -!- adam3us [~Adium@172.56.13.107] has quit [Quit: Leaving.] | 23:38 | |
| -!- Transisto [~Trans@modemcable017.87-131-66.mc.videotron.ca] has quit [Ping timeout: 240 seconds] | 23:48 | |
| -!- zooko [~user@68.233.149.129] has quit [Ping timeout: 240 seconds] | 23:51 | |
| -!- jtimon [~quassel@159.pool85-59-61.dynamic.orange.es] has quit [Ping timeout: 264 seconds] | 23:52 | |
Generated by irclog2html.py 2.15.0.dev0 by Marius Gedminas - find it at mg.pov.lt!