--- Day changed Tue Dec 23 2014
00:06 -!- 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:09 -!- pavel_ [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-wizards
00:10 -!- 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:11 -!- 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:12 -!- pavel_ [~paveljani@unaffiliated/paveljanik] has quit [Client Quit]
00:12 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-wizards
00:15 -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards
00:22 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards
00:24 -!- gues [~gues@cpe-66-68-54-206.austin.res.rr.com] has quit [Ping timeout: 245 seconds]
00:25 -!- 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:26 -!- 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:34 -!- MRL-Relay [~mrl-relay@coreteam.monero.cc] has quit [Ping timeout: 250 seconds]
00:35 -!- fluffypony [~fluffypon@unaffiliated/fluffypony] has quit [Ping timeout: 250 seconds]
00:40 -!- MRL-Relay [~mrl-relay@coreteam.monero.cc] has joined #bitcoin-wizards
00:40 -!- fluffypony [~fluffypon@unaffiliated/fluffypony] has joined #bitcoin-wizards
00:43 -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Remote host closed the connection]
00:44 < maaku> ok, yes i think there was an error in the code
00:46 -!- d1ggy [~d1ggy@dslb-088-073-244-129.088.073.pools.vodafone-ip.de] has quit [Ping timeout: 244 seconds]
00:48 -!- SubCreative is now known as Sub|zzz
00:49 -!- Sub|zzz is now known as SubCreative
00:49 -!- SubCreative is now known as Sub|zzz
01:00 -!- d1ggy [~d1ggy@dslb-088-073-244-129.088.073.pools.vodafone-ip.de] 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:05 -!- CoinMuncher [~jannes@178.132.211.90] has joined #bitcoin-wizards
01:08 -!- adam3us [~Adium@host-92-18-108-128.as13285.net] has joined #bitcoin-wizards
01:11 -!- hashtag_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards
01:12 -!- 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:20 < MRL-Relay> [smooth] .win1
01:35 -!- gues [gues@gateway/vpn/mullvad/x-bndujvmfjjohbope] has quit [Ping timeout: 250 seconds]
01:37 -!- 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:38 -!- NewLiberty_ [~NewLibert@2602:304:cff8:1580:6156:df06:de8a:8e51] has quit [Ping timeout: 258 seconds]
01:45 -!- vmatekole [~vmatekole@p5DC473BE.dip0.t-ipconnect.de] has joined #bitcoin-wizards
01:46 -!- vmatekole [~vmatekole@p5DC473BE.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
01:47 -!- 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
02:27 -!- GAit [~lnahum@enki.greenaddressit.p3.tiktalik.io] has quit [Remote host closed the connection]
02:36 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards
02:45 -!- hashtag_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 240 seconds]
02:47 -!- Baz__ [~Baz@70.81.31.147] has joined #bitcoin-wizards
02:48 -!- 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:49 -!- hashtag_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards
02:52 -!- afk11 [~androirc@108.61.122.195] has joined #bitcoin-wizards
02:55 -!- fanquake [~anonymous@unaffiliated/fanquake] has joined #bitcoin-wizards
02:55 -!- jtimon [~quassel@159.pool85-59-61.dynamic.orange.es] has joined #bitcoin-wizards
03:01 -!- bosma [~bosma@S01067cb21bda6531.vc.shawcable.net] has quit [Quit: Leaving]
03:02 -!- bosma [~bosma@S01067cb21bda6531.vc.shawcable.net] has joined #bitcoin-wizards
03:09 -!- 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:10 -!- 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:13 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Ping timeout: 244 seconds]
03:22 -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has joined #bitcoin-wizards
03:30 -!- 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:34 -!- afk11 [~androirc@108.61.122.156] has quit [Remote host closed the connection]
03:36 -!- 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:37 -!- gues [~gues@cpe-66-68-54-206.austin.res.rr.com] has quit [Ping timeout: 240 seconds]
03:39 -!- gues [~gues@193.138.219.233] has joined #bitcoin-wizards
03:41 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Ping timeout: 256 seconds]
03:42 -!- Grishnakh [~grishnakh@dsl-espbrasgw1-50dfb6-218.dhcp.inet.fi] has quit [Quit: Leaving]
03:43 -!- 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:51 -!- 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:53 -!- Quanttek [~quassel@ip1f12ed87.dynamic.kabel-deutschland.de] has quit [Ping timeout: 250 seconds]
03:54 -!- iang [~iang@188.29.165.77.threembb.co.uk] has joined #bitcoin-wizards
03:58 -!- iang [~iang@188.29.165.77.threembb.co.uk] has quit [Client Quit]
04:05 -!- adam3us [~Adium@host-92-19-8-76.as13285.net] has joined #bitcoin-wizards
04:07 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards
04:08 -!- adam3us1 [~Adium@host-92-18-108-128.as13285.net] has quit [Ping timeout: 240 seconds]
04:24 -!- 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)
--- Log closed Tue Dec 23 04:24:28 2014
--- Log opened Tue Dec 23 04:25:05 2014
04:25 -!- 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:26 -!- 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:27 -!- ahmed_ [sid14086@gateway/web/irccloud.com/x-zsjigvgjemkosldq] has quit [Max SendQ exceeded]
04:28 -!- 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:29 -!- 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:33 -!- 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:34 -!- hearn [~mike@cpc8-macc3-2-0-cust245.1-3.cable.virginm.net] has joined #bitcoin-wizards
04:45 -!- MoALTz [~no@user-164-126-31-182.play-internet.pl] has quit [Quit: Leaving]
04:49 -!- gues [~gues@193.138.219.233] has quit [Ping timeout: 265 seconds]
04:51 -!- gues [gues@gateway/vpn/mullvad/x-yqxywptftfdtuplv] has joined #bitcoin-wizards
04:52 -!- 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:55 -!- hashtag_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 244 seconds]
04:58 -!- cluckj [~cluckj@cpe-24-92-48-18.nycap.res.rr.com] has joined #bitcoin-wizards
04:59 -!- ahmed_ is now known as ahmed__
04:59 -!- ahmed__ [sid14086@gateway/web/irccloud.com/x-apsvfkyoldrjqvvf] has quit [Excess Flood]
05:01 -!- ahmed_ [sid14086@gateway/web/irccloud.com/x-hjnhqwvjimdbiqri] has joined #bitcoin-wizards
05:04 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection]
05:06 -!- belcher [~belcher-s@unaffiliated/belcher] has quit [Ping timeout: 252 seconds]
05:08 -!- 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:09 -!- d1ggy [~d1ggy@dslb-088-073-244-129.088.073.pools.vodafone-ip.de] has quit [Quit: Leaving]
05:10 -!- NewLiberty_ is now known as NewLiberty
05:13 -!- belcher [~belcher-s@unaffiliated/belcher] has joined #bitcoin-wizards
05:15 -!- Burrito [~Burrito@unaffiliated/burrito] has joined #bitcoin-wizards
05:18 -!- iang [~iang@188.29.164.243.threembb.co.uk] has quit [Quit: iang]
05:22 -!- aburan28 [~ubuntu@static-108-45-93-73.washdc.fios.verizon.net] has quit [Ping timeout: 256 seconds]
05:25 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit []
05:26 -!- 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:27 -!- 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:28 -!- belcher [~belcher-s@unaffiliated/belcher] has joined #bitcoin-wizards
05:42 -!- Profreid [~Profreitt@179.43.148.66] has joined #bitcoin-wizards
05:47 -!- Logicwax [~Logicwax@c-50-161-23-192.hsd1.ca.comcast.net] has quit [Quit: rm -rf /]
05:52 -!- 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:59 < nsh> gmaxwell, can you think of a pathological case in which a low-density parity-check algorithm would be nonterminating?
06:00 < 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:01 < 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:02 < 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:03 < 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:05 < nsh> hmm
06:09 -!- Logicwax [~Logicwax@c-50-161-23-192.hsd1.ca.comcast.net] has quit [Quit: rm -rf /]
06:14 -!- 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:18 -!- Logicwax [~Logicwax@c-50-161-23-192.hsd1.ca.comcast.net] has joined #bitcoin-wizards
06:19 -!- fanquake [~anonymous@unaffiliated/fanquake] has quit [Quit: fanquake]
06:25 -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Remote host closed the connection]
06:32 -!- hearn [~mike@cpc8-macc3-2-0-cust245.1-3.cable.virginm.net] has joined #bitcoin-wizards
06:36 -!- vmatekol_ [~vmatekole@p5DC473BE.dip0.t-ipconnect.de] has joined #bitcoin-wizards
06:38 -!- vmatekole [~vmatekole@p5DC473BE.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds]
06:42 -!- belcher [~belcher-s@unaffiliated/belcher] has quit [Read error: Connection reset by peer]
06:44 -!- 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:50 -!- vmatekol_ [~vmatekole@p5DC473BE.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
06:51 -!- vmatekole [~vmatekole@p5DC473BE.dip0.t-ipconnect.de] has joined #bitcoin-wizards
06:56 -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards
06:58 -!- 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:59 -!- maraoz [~maraoz@181.29.97.171] has joined #bitcoin-wizards
07:00 -!- zz_lnovy [~lnovy@2002:4d57:f055::1] has joined #bitcoin-wizards
07:00 -!- zz_lnovy is now known as lnovy
07:04 -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Remote host closed the connection]
07:12 -!- Logicwax [~Logicwax@c-50-161-23-192.hsd1.ca.comcast.net] has joined #bitcoin-wizards
07:13 -!- iang [~iang@188.29.164.243.threembb.co.uk] has quit [Quit: iang]
07:17 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection]
07:21 -!- hearn [~mike@cpc8-macc3-2-0-cust245.1-3.cable.virginm.net] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
07:25 -!- jtimon [~quassel@159.pool85-59-61.dynamic.orange.es] has quit [Ping timeout: 245 seconds]
07:26 -!- zooko [~user@68.233.149.129] has joined #bitcoin-wizards
07:29 -!- hearn [~mike@cpc8-macc3-2-0-cust245.1-3.cable.virginm.net] has joined #bitcoin-wizards
07:33 -!- Quanttek [~quassel@2a02:8108:d00:870:a40c:c46a:a2ae:81f8] has joined #bitcoin-wizards
07:37 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye]
07:43 -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards
07:49 -!- adam3us1 [~Adium@88-105-9-250.dynamic.dsl.as9105.com] has joined #bitcoin-wizards
07:52 -!- adam3us [~Adium@host-92-19-8-76.as13285.net] has quit [Ping timeout: 250 seconds]
07:54 -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Remote host closed the connection]
07:58 -!- 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
08:05 -!- drawingthesun [~drawingth@106-68-221-100.dyn.iinet.net.au] has joined #bitcoin-wizards
08:10 -!- drawingthesun [~drawingth@106-68-221-100.dyn.iinet.net.au] has quit [Ping timeout: 244 seconds]
08:29 -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has joined #bitcoin-wizards
08:33 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards
08:35 -!- 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:36 -!- iang [~iang@188.29.164.31.threembb.co.uk] has quit [Client Quit]
08:39 -!- gues [~gues@cpe-66-68-54-206.austin.res.rr.com] has joined #bitcoin-wizards
08:42 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye]
08:44 -!- gues [~gues@cpe-66-68-54-206.austin.res.rr.com] has quit [Ping timeout: 240 seconds]
09:08 -!- Shiftos [~shiftos@gateway/tor-sasl/shiftos] has quit [Ping timeout: 250 seconds]
09:09 -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has quit [Ping timeout: 250 seconds]
09:13 -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has joined #bitcoin-wizards
09:13 -!- Shiftos [~shiftos@gateway/tor-sasl/shiftos] has joined #bitcoin-wizards
09:14 -!- jtimon [~quassel@159.pool85-59-61.dynamic.orange.es] has quit [Ping timeout: 245 seconds]
09:20 -!- user7779078 [user777907@gateway/vpn/mullvad/x-jcbqgarjibpcwyyf] has joined #bitcoin-wizards
09:29 -!- hollandais [~irenacob@li629-190.members.linode.com] has quit [Remote host closed the connection]
09:32 -!- 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:35 -!- 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:46 -!- user7779078 [user777907@gateway/vpn/mullvad/x-jcbqgarjibpcwyyf] has quit []
10:05 -!- amarha [~EsteNuno@223.207.129.61] has joined #bitcoin-wizards
10:07 -!- user7779078 [user777907@gateway/vpn/mullvad/x-lvabzuqmwhiirjic] has joined #bitcoin-wizards
10:08 -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has joined #bitcoin-wizards
10:11 -!- Profreid [~Profreitt@179.43.148.66] has quit [Quit: Profreid]
10:20 -!- 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:25 -!- CoinMuncher [~jannes@178.132.211.90] has quit [Quit: Leaving.]
10:33 -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has quit [Quit: iang]
10:45 -!- 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:47 -!- Emcy [~MC@unaffiliated/mc1984] has quit [Ping timeout: 255 seconds]
10:48 -!- 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:53 -!- SDCDev [~quassel@unaffiliated/sdcdev] has joined #bitcoin-wizards
11:01 -!- belcher [~belcher-s@unaffiliated/belcher] has quit [Quit: Leaving]
11:01 -!- berndj [~berndj@azna.co.za] has quit [Quit: ZNC - http://znc.in]
11:02 -!- berndj [~berndj@azna.co.za] has joined #bitcoin-wizards
11:06 -!- 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:21 -!- Tjopper [~Jop@dhcp-077-249-237-229.chello.nl] has quit [Read error: Connection reset by peer]
11:23 -!- AdrianG_ is now known as AdrianG
11:23 -!- AdrianG is now known as Guest22332
11:24 -!- 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:25 < 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:27 < kanzure> nevermind, i'll just consider more edge cases on blockhash lookup opcodes
11:39 -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has joined #bitcoin-wizards
11:42 -!- kyletorpey [~kyle@c-24-131-0-5.hsd1.va.comcast.net] has quit [Quit: Leaving.]
11:46 -!- siraj [~siraj@adsl-68-93-64-210.dsl.hstntx.swbell.net] has joined #bitcoin-wizards
11:47 -!- 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:48 < 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:49 < 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:50 -!- 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:51 < 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:52 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards
11:53 < kanzure> spendonlyafter is very different though- it's making assurances in the opposite direction
11:54 < 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:55 < 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:56 < 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:57 < kanzure> ah, you mean if you use a "recent" blockhash
11:58 < 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:59 -!- kobud [wq@unaffiliated/fluffybunny] has quit [Remote host closed the connection]
12:00 -!- lclc_bnc is now known as lclc
12:01 -!- lclc [~lclc@bothniafur.com] has quit [Changing host]
12:01 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-wizards
12:02 < 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:03 < 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:04 < 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:05 < 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:06 < 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:08 < kanzure> and "get" would be what?
12:08 -!- adam3us [~Adium@88-105-25-192.dynamic.dsl.as9105.com] has joined #bitcoin-wizards
12:09 < 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:10 < 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:11 < 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:20 < 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:21 < 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:23 < 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:24 -!- 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:25 < 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:26 < 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:27 < 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:28 < kanzure> if the outputs you were spending originally happen to go missing, you can't know that they will always remain missing
12:30 < 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:31 < 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:32 < phantomcircuit> not particularly arguing for anything at this point, but making sure i understand what you were getting at
12:33 < 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:34 -!- 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:35 < 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:36 -!- 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:37 < 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:38 -!- 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:39 < 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:40 < 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:41 < 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:42 < 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:43 < 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:44 < 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:45 < 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:46 < 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:47 -!- 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:48 < 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:49 < 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:50 -!- 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:51 < 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:52 -!- belcher [~belcher-s@unaffiliated/belcher] has quit [Ping timeout: 244 seconds]
12:53 < 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:54  * 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:55 < sipa> petertodd: right, agree there
12:55 < petertodd> apt-get install pay-for-wifi-via-blockchain.info-account
12:56 < 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
13:02 -!- MoALTz [~no@user-164-126-31-182.play-internet.pl] has joined #bitcoin-wizards
13:03 -!- jps [~Jud@172.56.34.40] has quit [Quit: jps]
13:05 < 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:06 < petertodd> phantomcircuit: yup
13:07 < 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:08 < 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:09 -!- 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:10 -!- 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:11 < 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:12 < 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:13 < 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:14 < 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:15 < 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:16 < 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:17 < 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:18 < petertodd> calling this stuff "federated" is just a PR gimmick - albeit a good one..
13:21 -!- 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:22 < 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:23 < 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:24 < 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:26 < 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:27 < petertodd> sipa: I'm dangerously close to shaving a yak hurd and implementing that :P
13:28 < 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:30 < 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:31 < 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:32 < 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:33 < 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:34 < 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:39 -!- butters [~butters@dslb-178-008-078-133.178.008.pools.vodafone-ip.de] has joined #bitcoin-wizards
13:44 -!- vmatekole [~vmatekole@p5DC473BE.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds]
13:51 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection]
13:52 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards
13:56 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Ping timeout: 245 seconds]
14:10 -!- hashtag_ [~hashtag@cpe-98-157-219-44.ma.res.rr.com] has quit [Ping timeout: 252 seconds]
14:11 < phantomcircuit> i wonder how close power efficiency for aes-ni is compared to a gpu/fpga/asic
14:12 < 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:14 -!- waxwing [waxwing@gateway/vpn/mullvad/x-xpvatopenkfairhk] has quit [Ping timeout: 245 seconds]
14:15 -!- ryanxcharles [~ryanxchar@2601:9:4680:dd0:70b4:ef77:81f:8211] has joined #bitcoin-wizards
14:20 -!- adam3us [~Adium@88-105-25-192.dynamic.dsl.as9105.com] has quit [Quit: Leaving.]
14:27 -!- waxwing [~waxwing@62.205.214.125] has joined #bitcoin-wizards
14:29 -!- AnoAnon [~AnoAnon@197.37.57.96] has joined #bitcoin-wizards
14:30 -!- 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:35 -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Ping timeout: 250 seconds]
14:46 -!- jps [~Jud@172.56.22.91] has joined #bitcoin-wizards
14:47 -!- jps [~Jud@172.56.22.91] has quit [Client Quit]
15:00 -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has quit [Quit: Leaving]
15:01 -!- devrandom [~devrandom@gateway/tor-sasl/niftyzero1] has quit [Quit: leaving]
15:04 -!- atgreen [~user@CPE687f74122463-CM84948c2e0610.cpe.net.cable.rogers.com] has quit [Ping timeout: 252 seconds]
15:05 -!- Guest22056 [~omni@ip68-4-111-228.oc.oc.cox.net] has quit []
15:06 -!- fanquake [~anonymous@unaffiliated/fanquake] has joined #bitcoin-wizards
15:06 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
15:08 -!- omni [~omni@ip68-4-111-228.oc.oc.cox.net] has joined #bitcoin-wizards
15:08 -!- omni is now known as Guest44359
15:12 -!- maraoz [~maraoz@181.29.97.171] has quit [Ping timeout: 240 seconds]
15:22 -!- hashtag_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards
15:27 -!- user7779078 [user777907@gateway/vpn/mullvad/x-lvabzuqmwhiirjic] has quit [Remote host closed the connection]
15:31 -!- HaltingState [~HaltingSt@unaffiliated/haltingstate] has joined #bitcoin-wizards
15:31 -!- Shiftos [~shiftos@gateway/tor-sasl/shiftos] has quit [Remote host closed the connection]
15:35 < rusty> maaku: thanks, applying your pull requests now.  Will have to create ascii art explaining MMR tree, once I understand it :)
15:38 -!- thrasher` [~thrasher@27-33-27-140.static.tpgi.com.au] has joined #bitcoin-wizards
15:49 -!- gues [~gues@172-7-226-202.lightspeed.hstntx.sbcglobal.net] has joined #bitcoin-wizards
15:51 -!- bosma [~bosma@S01067cb21bda6531.vc.shawcable.net] has quit [Quit: Leaving]
15:52 -!- fanquake [~anonymous@unaffiliated/fanquake] has quit [Quit: fanquake]
15:54 -!- gues [~gues@172-7-226-202.lightspeed.hstntx.sbcglobal.net] has quit [Ping timeout: 244 seconds]
15:56 -!- 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]
16:00 -!- Shiftos [~shiftos@gateway/tor-sasl/shiftos] has joined #bitcoin-wizards
16:02 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
16:15 -!- epscy [~epscy@176.126.241.239] has joined #bitcoin-wizards
16:17 -!- 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:19 -!- gues [gues@gateway/vpn/mullvad/x-lhvdnuaclhttcdlt] has joined #bitcoin-wizards
16:20 -!- MoALTz_ [~no@user-164-126-31-182.play-internet.pl] has joined #bitcoin-wizards
16:23 -!- MoALTz [~no@user-164-126-31-182.play-internet.pl] has quit [Ping timeout: 244 seconds]
16:25 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit []
16:27 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards
16:35 -!- siervo [uid49244@gateway/web/irccloud.com/x-stdrwnesmlxmqyjf] has joined #bitcoin-wizards
16:36 -!- Cory [~Cory@unaffiliated/cory] has quit []
16:55 -!- Cory [~Cory@unaffiliated/cory] has joined #bitcoin-wizards
16:56 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
16:58 -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has joined #bitcoin-wizards
17:00 < 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:03 -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has quit [Client Quit]
17:04 -!- Dizzle [~Dizzle@pool-108-44-72-46.ronkva.east.verizon.net] has quit [Quit: Leaving...]
17:05 -!- moa [~kiwigb@opentransactions/dev/moa] has quit [Quit: Leaving.]
17:12 -!- afk11 [~afk11@dsl-088-099.cust.imagine.ie] has joined #bitcoin-wizards
17:15 -!- 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:19 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 252 seconds]
17:20 -!- atgreen [~user@CPE687f74122463-CM84948c2e0610.cpe.net.cable.rogers.com] has joined #bitcoin-wizards
17:20 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-wizards
17:23 -!- orik [~orik@50-46-132-219.evrt.wa.frontiernet.net] has joined #bitcoin-wizards
17:26 -!- afk11 [~afk11@dsl-088-099.cust.imagine.ie] has quit [Ping timeout: 245 seconds]
17:34 < rusty> maaku: ... or my tree implementation is buggy...
17:40 -!- 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:43 -!- 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:45 -!- 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:51 < petertodd> rusty: is that repo up on github?
17:51 < rusty> petertodd: I'll push now, one sec.
17:52 < 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:53 -!- 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:54 < 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:55 < faraka> what do you think about codius peter?
17:56 < 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:58 -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Ping timeout: 250 seconds]
18:03 < 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:04 < 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:05 < 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:06 < petertodd> rusty: lol
18:07 < 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:08 < 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:09 -!- 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:11 < 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:12 -!- belcher [~belcher-s@unaffiliated/belcher] has quit [Quit: Leaving]
18:13 < rusty> maaku: how embarrassing, you relied on my rfc6962 code, which was buggy....
18:14 < 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:15 < 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:16 < 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:17 < 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:18 < 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:19 -!- 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:20 < rusty> petertodd: that was the suggestion, though I'm ignoring it for my comparison work.
18:21 < petertodd> rusty: one consideration there might be the shape of hashrate growth - be interesting if non-stready states change it
18:22 < 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:23 < petertodd> gmaxwell: sure, but what about high variable? particularly maliciously constructed highly variable cases
18:24 < gmaxwell> petertodd: if you grind away long backlinks you can force it to linear scaling at tremendous computational cost.
18:25 < gmaxwell> (e.g. assuming you were a majority hashpower attacker)
18:26 < rusty> gmaxwell: not really, since replacing 1 in 16 blocks would have significant effect.
18:27 < 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:28 < 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:29 < gmaxwell> sure sure, one should strive for byzantine security though; when possible.
18:30 < 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:32 < 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:33 -!- 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:34 < 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:36 -!- 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:37 < 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:38 < 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:39 < 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:40 < 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:41 < rusty> ^^
18:42 < 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:43 < 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:44 < 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:45 < 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:46 < 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:47 < 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:48 < maaku> (for the mountain bagging step)
18:49 < maaku> it lacks bitcoind's repeat-the-hash step, and so creates unbalanced trees
18:49 < maaku> hi rusty
18:50 < 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:52 < 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:53 < 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:54 < 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:55 < 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:56 < 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:57 < 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
19:01 < maaku> rusty: nevermind you changed the peak ordering, so this should be correct
19:01 < maaku> rusty: it generated different numbers though?
19:02 < rusty> maaku: yeah... now I'm looking at the trees to figure out what the difference in topologies actually is...
19:03 < 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:05 < 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:08 -!- 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:09 < 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:10 < 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:11 < 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:12 < petertodd> and I published that Oc 21 2012, a good 7 months before RFC6962 :P
19:13 < 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:19 < 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:20 < 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:24 -!- Quanttek [~quassel@2a02:8108:d00:870:a40c:c46a:a2ae:81f8] has quit [Remote host closed the connection]
19:26 -!- user7779078 [~user77790@193.138.219.233] has joined #bitcoin-wizards
19:32 -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards
19:34 -!- afk11 [~afk11@dsl-088-099.cust.imagine.ie] has quit [Ping timeout: 245 seconds]
19:36 -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Ping timeout: 250 seconds]
19:43 -!- siervo [uid49244@gateway/web/irccloud.com/x-stdrwnesmlxmqyjf] has quit []
19:45 -!- user7779078 [~user77790@193.138.219.233] has quit [Remote host closed the connection]
19:46 < 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:47 < maaku> well we go the other way, but it's transoformable to operate in that direction
19:50 < maaku> rusty: btw just pulled and it doesn't compile
19:51 -!- 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:52 < 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:53 < 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:54 < 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:56 < maaku> * take left branch to access a decision branch for the next peak
19:57 < rusty> maaku: my *gut* feeling is that it will punish long jumps too much, but I could be wrong.
19:58 < 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:59 < 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]
20:03 < maaku> rusty: are you doing some sort of dynamic programming to find the shortest paths?
20:04 < 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:06 < maaku> rusty: right you always need one branch. i think you mean mtns == 0
20:07 < 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:08 < 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:09 < 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:11 -!- Burrito [~Burrito@unaffiliated/burrito] has quit [Ping timeout: 265 seconds]
20:12 -!- christo [~christo@eth59-167-133-100.static.internode.on.net] has joined #bitcoin-wizards
20:28 < 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:30 -!- beamlaser [49cc4c7f@gateway/web/freenode/ip.73.204.76.127] has joined #bitcoin-wizards
20:31 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 265 seconds]
20:32 < beamlaser> does anyone know of multisig threshold implementation in java?
20:33 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards
20:42 -!- 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:47 -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Ping timeout: 250 seconds]
20:51 -!- coiner [~linker@1.54.73.86] has quit [Ping timeout: 255 seconds]
20:53 -!- beamlaser [49cc4c7f@gateway/web/freenode/ip.73.204.76.127] has quit [Ping timeout: 246 seconds]
20:57 < 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:59 < rusty> Still, a factor of 12000 times is nothing to sneeze at.
21:08 -!- Transisto [~Trans@modemcable017.87-131-66.mc.videotron.ca] has joined #bitcoin-wizards
21:17 -!- siraj [~siraj@adsl-68-93-67-122.dsl.hstntx.swbell.net] has joined #bitcoin-wizards
21:23 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:a9dd:bf2d:7ebb:12ec] has quit [Ping timeout: 258 seconds]
21:26 -!- christo [~christo@eth59-167-133-100.static.internode.on.net] has quit [Remote host closed the connection]
21:41 -!- MoALTz [~no@user-164-126-31-182.play-internet.pl] has joined #bitcoin-wizards
21:42 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
21:44 -!- 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:47 -!- Dr-G3 [~Dr-G@gateway/tor-sasl/dr-g] has quit [Ping timeout: 250 seconds]
21:52 -!- Dr-G3 [~Dr-G@gateway/tor-sasl/dr-g] has joined #bitcoin-wizards
21:55 -!- Guest89604 [~Pan0ram1x@095-096-084-122.static.chello.nl] has quit [Ping timeout: 245 seconds]
21:58 -!- coiner [~linker@113.161.87.238] has joined #bitcoin-wizards
22:01 -!- Pan0ram1x [~Pan0ram1x@095-096-084-122.static.chello.nl] has joined #bitcoin-wizards
22:02 -!- Pan0ram1x is now known as Guest2745
22:15 -!- ryanxcharles [~ryanxchar@2601:9:4680:dd0:70b4:ef77:81f:8211] has quit [Ping timeout: 258 seconds]
22:19 -!- ryanxcharles [~ryanxchar@2601:9:4680:dd0:70b4:ef77:81f:8211] has joined #bitcoin-wizards
22:32 -!- koshii [~0@c-68-58-151-30.hsd1.in.comcast.net] has quit [Quit: leaving]
22:33 -!- user7779078 [~user77790@c-73-1-104-107.hsd1.fl.comcast.net] has joined #bitcoin-wizards
22:39 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 244 seconds]
22:40 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-wizards
22:47 -!- Dizzle [~Dizzle@pool-108-44-72-46.ronkva.east.verizon.net] has joined #bitcoin-wizards
22:52 -!- koshii [~0@c-68-58-151-30.hsd1.in.comcast.net] has joined #bitcoin-wizards
22:58 -!- aburan28 [~ubuntu@107.107.60.166] has joined #bitcoin-wizards
23:05 -!- jtimon [~quassel@159.pool85-59-61.dynamic.orange.es] has joined #bitcoin-wizards
23:24 -!- user7779078 [~user77790@c-73-1-104-107.hsd1.fl.comcast.net] has quit [Ping timeout: 265 seconds]
23:33 -!- adam3us [~Adium@172.56.13.107] has joined #bitcoin-wizards
23:38 -!- 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:48 -!- Transisto [~Trans@modemcable017.87-131-66.mc.videotron.ca] has quit [Ping timeout: 240 seconds]
23:51 -!- zooko [~user@68.233.149.129] has quit [Ping timeout: 240 seconds]
23:52 -!- jtimon [~quassel@159.pool85-59-61.dynamic.orange.es] has quit [Ping timeout: 264 seconds]