--- Day changed Thu Dec 18 2014
00:02 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:4df6:1bba:6991:75f0] has joined #bitcoin-wizards
00:04 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has joined #bitcoin-wizards
00:06 -!- HaltingState [~HaltingSt@unaffiliated/haltingstate] has joined #bitcoin-wizards
00:10 -!- bitbumper [~bitbumper@161.47.143.24.cm.sunflower.com] has quit [Ping timeout: 265 seconds]
00:11 -!- bitbumper [~bitbumper@161.47.143.24.cm.sunflower.com] has joined #bitcoin-wizards
00:14 -!- grau [~grau@37.143.74.116] has joined #bitcoin-wizards
00:15 -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards
00:17 -!- vmatekole [~vmatekole@p5DC478FC.dip0.t-ipconnect.de] has joined #bitcoin-wizards
00:20 -!- nessence [~alexl@178.19.221.38] has joined #bitcoin-wizards
00:21 < adam3us> bramc: another kdf (secure delegatable) you might find interesting https://bitcointalk.org/index.php?topic=311000.0 as it allows much larger kdf parameters if people are willing to pay a fraction of a cent to gpu miners to do the work.
00:22 < adam3us> which is a new idea for kdfs.  there's now someone on the kdf competition who has reinvented a similar idea.  both using rivest-wagner time-lock puzzle mechanism as the underlying.
00:23 < adam3us> thomas pornin's variant is called makwa https://password-hashing.net/submissions/specs/Makwa-v0.pdf
00:24 -!- bosma_ [~bosma@S01067cb21bda6531.vc.shawcable.net] has joined #bitcoin-wizards
00:24 -!- mkarrer_ [~mkarrer@135.Red-83-52-38.dynamicIP.rima-tde.net] has joined #bitcoin-wizards
00:25 -!- nessence [~alexl@178.19.221.38] has quit [Ping timeout: 272 seconds]
00:25 < bramc> adam3us, Thanks, I've added those to my list of stuff to go over
00:26 < bramc> It seems to take an average of two days to knock something off my list of stuff to go over. Unfortunately I've been adding a new thing about once every two days.
00:26 -!- mkarrer [~mkarrer@135.Red-83-52-38.dynamicIP.rima-tde.net] has quit [Ping timeout: 240 seconds]
00:26 -!- bosma [~bosma@S01067cb21bda6531.vc.shawcable.net] has quit [Ping timeout: 240 seconds]
00:28 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving]
00:28 -!- soundx_ [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards
00:31 -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Ping timeout: 250 seconds]
00:32 -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards
00:36 -!- lclc_bnc is now known as lclc
00:43 -!- coiner [~linker@113.161.87.238] has joined #bitcoin-wizards
00:45 -!- bit2017 [~linker@113.161.87.238] has quit [Ping timeout: 244 seconds]
00:47 -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Remote host closed the connection]
00:48 -!- soundx_ [~soundx@gateway/tor-sasl/soundx] has quit [Remote host closed the connection]
00:49 -!- jb55_ [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards
00:51 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
00:53 -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has quit [Quit: Leaving]
01:03 -!- CoinMuncher [~jannes@178.132.211.90] has joined #bitcoin-wizards
01:03 -!- tacotime [~mashkeys@198.52.200.63] has quit [Ping timeout: 245 seconds]
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:06 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards
01:10 -!- NewLiberty_ [~NewLibert@2602:304:cff8:1580:4df6:1bba:6991:75f0] has joined #bitcoin-wizards
01:13 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:4df6:1bba:6991:75f0] has quit [Ping timeout: 258 seconds]
01:15 -!- Profreid [~Profreitt@46.19.140.62] has joined #bitcoin-wizards
01:16 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 272 seconds]
01:20 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection]
01:20 -!- nessence [~alexl@178.19.221.38] has joined #bitcoin-wizards
01:25 -!- nessence [~alexl@178.19.221.38] has quit [Ping timeout: 265 seconds]
01:29 -!- lclc is now known as lclc_bnc
01:33 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards
01:36 -!- NewLiberty_ [~NewLibert@2602:304:cff8:1580:4df6:1bba:6991:75f0] has quit [Ping timeout: 258 seconds]
01:40 -!- moa [~kiwigb@opentransactions/dev/moa] has quit [Quit: Leaving.]
01:50 -!- Guest35090 [~chatzilla@96-41-48-194.dhcp.mtpk.ca.charter.com] has quit [Quit: ChatZilla 0.9.90.1 [SeaMonkey 2.22.1/20131113180422]]
01:51 -!- bifforoni [~zorin@bzq-84-108-84-113.cablep.bezeqint.net] has joined #bitcoin-wizards
01:52 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has joined #bitcoin-wizards
01:56 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has quit [Ping timeout: 245 seconds]
02:00 -!- lclc_bnc is now known as lclc
02:01 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection]
02:06 -!- woah [~woah@199-241-202-232.PUBLIC.monkeybrains.net] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
02:08 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards
02:20 -!- nessence [~alexl@178.19.221.38] has joined #bitcoin-wizards
02:25 -!- nessence [~alexl@178.19.221.38] has quit [Ping timeout: 256 seconds]
02:26 -!- jtimon [~quassel@145.pool85-53-220.dynamic.orange.es] has joined #bitcoin-wizards
02:33 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
02:40 -!- jb55_ [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Remote host closed the connection]
02:41 -!- GAit [~lnahum@enki.greenaddressit.p3.tiktalik.io] has joined #bitcoin-wizards
02:41 -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards
02:43 -!- jb55_ [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards
02:44 -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Read error: Connection reset by peer]
02:48 -!- jb55_ [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Remote host closed the connection]
02:48 -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards
02:52 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has joined #bitcoin-wizards
02:53 -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Ping timeout: 256 seconds]
02:54 -!- grau [~grau@37.143.74.116] has quit [Remote host closed the connection]
02:54 -!- grau [~grau@37.143.74.116] has joined #bitcoin-wizards
02:58 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds]
03:08 -!- orik [~orik@c-71-231-78-253.hsd1.wa.comcast.net] has joined #bitcoin-wizards
03:08 -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has joined #bitcoin-wizards
03:08 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards
03:09 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
03:18 -!- Profreid [~Profreitt@46.19.140.62] has quit [Quit: Profreid]
03:20 -!- nessence [~alexl@178.19.221.38] has joined #bitcoin-wizards
03:22 -!- grau [~grau@37.143.74.116] has quit [Remote host closed the connection]
03:24 -!- nessence [~alexl@178.19.221.38] has quit [Ping timeout: 245 seconds]
03:30 -!- grau [~grau@37.143.74.116] has joined #bitcoin-wizards
03:31 -!- gues [~gues@cpe-66-68-54-206.austin.res.rr.com] has quit [Read error: Connection reset by peer]
03:31 -!- nullbyte [~WW@unaffiliated/loteriety] has quit [Read error: Connection reset by peer]
03:32 -!- gues [~gues@cpe-66-68-54-206.austin.res.rr.com] has joined #bitcoin-wizards
03:34 -!- Adlai [~Adlai@gateway/tor-sasl/adlai] has joined #bitcoin-wizards
03:42 -!- gues [~gues@cpe-66-68-54-206.austin.res.rr.com] has quit [Read error: Connection reset by peer]
03:43 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards
03:48 -!- grau [~grau@37.143.74.116] has quit [Remote host closed the connection]
03:48 -!- gues [~gues@cpe-66-68-54-206.austin.res.rr.com] has joined #bitcoin-wizards
03:53 -!- cbeams_ [~cbeams@213.153.61.201] has joined #bitcoin-wizards
03:53 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has joined #bitcoin-wizards
03:55 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Ping timeout: 272 seconds]
03:58 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
03:59 -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards
04:10 -!- grau [~grau@37.143.74.116] has joined #bitcoin-wizards
04:13 -!- atgreen` [~user@CPE687f74122463-CM84948c2e0610.cpe.net.cable.rogers.com] has quit [Remote host closed the connection]
04:16 -!- austinhill [~Adium@bas11-montrealak-1177755981.dsl.bell.ca] has quit [Quit: Leaving.]
04:20 -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Remote host closed the connection]
04:20 -!- nessence [~alexl@178.19.221.38] has joined #bitcoin-wizards
04:22 -!- adam3us [~Adium@88-105-16-245.dynamic.dsl.as9105.com] has quit [Quit: Leaving.]
04:23 -!- jb55 [~jb55@204.239.250.1] has joined #bitcoin-wizards
04:25 -!- nessence [~alexl@178.19.221.38] has quit [Ping timeout: 272 seconds]
04:28 -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards
04:30 -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has quit [Ping timeout: 250 seconds]
04:31 -!- adam3us [~Adium@88-105-16-245.dynamic.dsl.as9105.com] has joined #bitcoin-wizards
04:34 -!- NewLiberty_ [~NewLibert@76-255-129-88.lightspeed.irvnca.sbcglobal.net] has joined #bitcoin-wizards
04:36 -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Remote host closed the connection]
04:36 -!- lclc is now known as lclc_bnc
04:37 -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards
04:38 -!- lclc_bnc is now known as lclc
04:38 -!- lclc is now known as lclc_bnc
04:44 -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Remote host closed the connection]
04:45 -!- jaromil [~jaromil@f1x.eu] has quit [Ping timeout: 250 seconds]
04:46 -!- cbeams_ [~cbeams@213.153.61.201] has quit [Remote host closed the connection]
04:48 -!- jb55 [~jb55@204.239.250.1] has quit [Remote host closed the connection]
04:54 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has joined #bitcoin-wizards
04:59 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has quit [Ping timeout: 245 seconds]
05:01 -!- bitbumper [~bitbumper@161.47.143.24.cm.sunflower.com] has quit [Ping timeout: 250 seconds]
05:05 -!- nullbyte [~WW@cpe-66-68-54-206.austin.res.rr.com] has joined #bitcoin-wizards
05:05 -!- nullbyte [~WW@cpe-66-68-54-206.austin.res.rr.com] has quit [Changing host]
05:05 -!- nullbyte [~WW@unaffiliated/loteriety] has joined #bitcoin-wizards
05:09 -!- adam3us [~Adium@88-105-16-245.dynamic.dsl.as9105.com] has quit [Ping timeout: 245 seconds]
05:11 -!- adam3us [~Adium@host-92-18-97-15.as13285.net] has joined #bitcoin-wizards
05:20 -!- HaltingState [~HaltingSt@unaffiliated/haltingstate] has quit [Quit: Leaving]
05:20 -!- nessence [~alexl@178.19.221.38] has joined #bitcoin-wizards
05:21 -!- hashtagg_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 255 seconds]
05:21 -!- nullbyte [~WW@unaffiliated/loteriety] has quit [Ping timeout: 256 seconds]
05:25 -!- nessence [~alexl@178.19.221.38] has quit [Ping timeout: 250 seconds]
05:34 -!- Quanttek [~quassel@2a02:8108:d00:870:5da3:245:115e:9159] has joined #bitcoin-wizards
05:38 -!- grau [~grau@37.143.74.116] has quit [Remote host closed the connection]
05:39 -!- HaltingState [~HaltingSt@unaffiliated/haltingstate] has joined #bitcoin-wizards
05:50 -!- grau [~grau@37.143.74.116] has joined #bitcoin-wizards
05:55 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has joined #bitcoin-wizards
05:55 -!- wallet421 [~wallet42@g225012206.adsl.alicedsl.de] has joined #bitcoin-wizards
05:55 -!- wallet421 [~wallet42@g225012206.adsl.alicedsl.de] has quit [Changing host]
05:55 -!- wallet421 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards
05:55 -!- wallet42 is now known as Guest25226
05:55 -!- Guest25226 [~wallet42@unaffiliated/wallet42] has quit [Killed (hitchcock.freenode.net (Nickname regained by services))]
05:55 -!- wallet421 is now known as wallet42
05:58 -!- dansmith_btc [~dansmith@85.25.117.24] has quit [Changing host]
05:58 -!- dansmith_btc [~dansmith@unaffiliated/dansmith-btc/x-0355117] has joined #bitcoin-wizards
05:59 -!- adam3us1 [~Adium@host-92-18-105-108.as13285.net] has joined #bitcoin-wizards
05:59 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has quit [Ping timeout: 256 seconds]
06:01 -!- adam3us [~Adium@host-92-18-97-15.as13285.net] has quit [Ping timeout: 255 seconds]
06:09 -!- gigavps [~me@107.146.23.84] has joined #bitcoin-wizards
06:17 -!- jaromil [~jaromil@f1x.eu] has joined #bitcoin-wizards
06:19 -!- jaromil [~jaromil@f1x.eu] has quit [Client Quit]
06:20 -!- hashtag [~hashtag@cpe-98-157-219-44.ma.res.rr.com] has joined #bitcoin-wizards
06:20 -!- nessence [~alexl@178.19.221.38] has joined #bitcoin-wizards
06:23 -!- jaromil [~jaromil@f1x.eu] has joined #bitcoin-wizards
06:23 -!- prodatalab [~prodatala@c-69-254-45-177.hsd1.fl.comcast.net] has quit [Quit: Konversation terminated!]
06:25 -!- nessence [~alexl@178.19.221.38] has quit [Ping timeout: 264 seconds]
06:25 -!- prodatalab [~prodatala@c-69-254-45-177.hsd1.fl.comcast.net] has joined #bitcoin-wizards
06:26 -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards
06:31 -!- grau [~grau@37.143.74.116] has quit [Remote host closed the connection]
06:38 -!- coiner [~linker@113.161.87.238] has quit [Ping timeout: 264 seconds]
06:56 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has joined #bitcoin-wizards
07:01 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds]
07:04 -!- toddf [~todd@2605:6400:20:8a57::] has joined #bitcoin-wizards
07:07 -!- coiner [~linker@183.80.130.202] has joined #bitcoin-wizards
07:09 -!- coiner [~linker@183.80.130.202] has quit [Max SendQ exceeded]
07:09 -!- coiner [~linker@183.80.130.202] has joined #bitcoin-wizards
07:10 -!- coiner [~linker@183.80.130.202] has quit [Max SendQ exceeded]
07:10 -!- coiner [~linker@183.80.130.202] has joined #bitcoin-wizards
07:11 -!- coiner [~linker@183.80.130.202] has quit [Max SendQ exceeded]
07:12 -!- coiner [~linker@183.80.130.202] has joined #bitcoin-wizards
07:15 -!- tacotime [~mashkeys@198.52.200.63] has joined #bitcoin-wizards
07:18 -!- grau [~grau@37.143.74.116] has joined #bitcoin-wizards
07:20 -!- nessence [~alexl@178.19.221.38] has joined #bitcoin-wizards
07:24 -!- nessence [~alexl@178.19.221.38] has quit [Ping timeout: 245 seconds]
07:28 -!- Emcy_ [~MC@unaffiliated/mc1984] has quit [Read error: Connection reset by peer]
07:30 -!- nessence [~alexl@178.19.221.38] has joined #bitcoin-wizards
07:31 -!- bitbumper [~bitbumper@129.237.222.1] has joined #bitcoin-wizards
07:37 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has left #bitcoin-wizards []
07:37 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards
07:46 -!- treehug88 [~treehug88@static-96-239-100-47.nycmny.fios.verizon.net] has joined #bitcoin-wizards
07:48 -!- maraoz [~maraoz@181.29.97.171] has joined #bitcoin-wizards
07:51 -!- vmatekole [~vmatekole@p5DC478FC.dip0.t-ipconnect.de] has quit [Read error: Connection timed out]
07:52 -!- vmatekole [~vmatekole@p5DC478FC.dip0.t-ipconnect.de] has joined #bitcoin-wizards
07:53 -!- bitbumper [~bitbumper@129.237.222.1] has quit [Ping timeout: 244 seconds]
07:56 -!- op_mul [~op_mul@2a03:b0c0:2:d0::1:6001] has quit [Quit: Lost terminal]
07:57 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has joined #bitcoin-wizards
07:58 -!- Profreid [~Profreitt@179.43.134.2] has joined #bitcoin-wizards
07:58 -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has joined #bitcoin-wizards
08:01 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has quit [Ping timeout: 245 seconds]
08:03 -!- Emcy [~MC@unaffiliated/mc1984] has joined #bitcoin-wizards
08:03 -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Remote host closed the connection]
08:07 -!- adam3us1 [~Adium@host-92-18-105-108.as13285.net] has quit [Quit: Leaving.]
08:10 -!- gigavps [~me@107.146.23.84] has quit [Remote host closed the connection]
08:11 -!- huseby is now known as husebyAFK
08:11 -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards
08:15 -!- rfreeman_w [~rfreeman@gateway/tor-sasl/rfreemanw] has joined #bitcoin-wizards
08:22 -!- rfreeman_w [~rfreeman@gateway/tor-sasl/rfreemanw] has quit [Remote host closed the connection]
08:23 -!- rfreeman_w [~rfreeman@gateway/tor-sasl/rfreemanw] has joined #bitcoin-wizards
08:23 -!- rfreeman_w [~rfreeman@gateway/tor-sasl/rfreemanw] has quit [Remote host closed the connection]
08:26 -!- rfreeman_w [~rfreeman@gateway/tor-sasl/rfreemanw] has joined #bitcoin-wizards
08:26 -!- nessence [~alexl@178.19.221.38] has quit [Remote host closed the connection]
08:27 -!- nessence [~alexl@178.19.221.38] has joined #bitcoin-wizards
08:27 -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Remote host closed the connection]
08:29 -!- Profreid [~Profreitt@179.43.134.2] has quit [Quit: Profreid]
08:29 -!- rfreeman_w [~rfreeman@gateway/tor-sasl/rfreemanw] has quit [Remote host closed the connection]
08:30 -!- rfreeman_w [~rfreeman@gateway/tor-sasl/rfreemanw] has joined #bitcoin-wizards
08:38 -!- rfreeman_w [~rfreeman@gateway/tor-sasl/rfreemanw] has quit [Ping timeout: 250 seconds]
08:46 -!- adam3us [~Adium@host-92-18-105-108.as13285.net] has joined #bitcoin-wizards
08:46 -!- grau [~grau@37.143.74.116] has quit [Remote host closed the connection]
08:46 -!- grau [~grau@37.143.74.116] has joined #bitcoin-wizards
08:47 -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has joined #bitcoin-wizards
08:47 -!- adam3us1 [~Adium@host-92-18-105-108.as13285.net] has joined #bitcoin-wizards
08:48 -!- adam3us [~Adium@host-92-18-105-108.as13285.net] has quit [Read error: Connection reset by peer]
08:52 -!- ryanxcharles [~ryanxchar@c-67-169-47-156.hsd1.ca.comcast.net] has quit [Ping timeout: 272 seconds]
08:54 -!- nessence [~alexl@178.19.221.38] has quit [Remote host closed the connection]
08:54 -!- Profreid [~Profreitt@179.43.134.2] has joined #bitcoin-wizards
08:57 -!- rfreeman_w [~rfreeman@gateway/tor-sasl/rfreemanw] has joined #bitcoin-wizards
08:58 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has joined #bitcoin-wizards
09:03 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds]
09:04 -!- Starduster [~guest@unaffiliated/starduster] has quit [Read error: Connection reset by peer]
09:04 -!- Starduster [~guest@unaffiliated/starduster] has joined #bitcoin-wizards
09:22 -!- lclc_bnc is now known as lclc
09:23 -!- adam3us1 [~Adium@host-92-18-105-108.as13285.net] has quit [Read error: Connection reset by peer]
09:24 -!- adam3us [~Adium@host-92-18-104-28.as13285.net] has joined #bitcoin-wizards
09:24 -!- rfreeman_w [~rfreeman@gateway/tor-sasl/rfreemanw] has quit [Ping timeout: 250 seconds]
09:28 -!- ryanxcharles [~ryanxchar@162-245-22-162.v250d.PUBLIC.monkeybrains.net] has joined #bitcoin-wizards
09:29 -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
09:30 -!- rfreeman_w [~rfreeman@gateway/tor-sasl/rfreemanw] has joined #bitcoin-wizards
09:51 -!- nessence [~alexl@178.19.221.38] has joined #bitcoin-wizards
09:53 -!- devrando1 [~devrandom@142-254-47-143.dsl.dynamic.sonic.net] has joined #bitcoin-wizards
09:54 -!- devrando1 is now known as devrandom
09:54 -!- devrandom [~devrandom@142-254-47-143.dsl.dynamic.sonic.net] has quit [Changing host]
09:54 -!- devrandom [~devrandom@unaffiliated/niftyzero1] has joined #bitcoin-wizards
09:54 -!- devrandom [~devrandom@unaffiliated/niftyzero1] has quit [Client Quit]
09:54 -!- devrando1 [~devrandom@142-254-47-143.dsl.dynamic.sonic.net] has joined #bitcoin-wizards
09:56 -!- devrando1 is now known as devrandom
09:56 -!- devrandom [~devrandom@142-254-47-143.dsl.dynamic.sonic.net] has quit [Changing host]
09:56 -!- devrandom [~devrandom@unaffiliated/niftyzero1] has joined #bitcoin-wizards
09:58 -!- Profreid [~Profreitt@179.43.134.2] has quit [Quit: Profreid]
09:58 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has joined #bitcoin-wizards
10:00 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye]
10:03 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds]
10:06 -!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has joined #bitcoin-wizards
10:06 -!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has quit [Changing host]
10:06 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards
10:07 -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards
10:10 -!- jasonw22 [~jasonw22@208.74.176.33.static.etheric.net] has joined #bitcoin-wizards
10:10 < bramc> It turns out I was half wrong about hardware depreciation. While it's possible to favor depreciating hardware over custom built hardware, the amount spent in total will be the same. The problem is that there's too much depreciating hardware out there, and as long as the amount of electricity which can potentially be used across *all* that hardware is greater than the value of the mining rewards, that amount will get used
10:10 < bramc>  up
10:12 < bramc> That said, it might be possible to favor depreciating hardware over custom hardware, but the potential for making something green isn't great. The best way to make cryptocurrencies be green is to lower mining rewards, and any new cryptocurrency is of course increasing mining rewards by making another pool of them
10:12 -!- Quanttek [~quassel@2a02:8108:d00:870:5da3:245:115e:9159] has quit [Ping timeout: 272 seconds]
10:13 < sipa> in an equilibrium with globally constant prices, the mining reward is equal to hardware + electricity costs
10:14 -!- NikolaiToryzin [~stqism@freebsd/user/stqism] has quit [Ping timeout: 258 seconds]
10:14 < sipa> and also directly related to the security of the system (if miners get more from subsidy (+ fees) than by attacking, you can assume they won't)
10:14 < sipa> and assuming the security level is sort-of a choice made by the users of the system, you can't really set it at the start in the rules
10:14 < sipa> as the exchange rate remains a free-floating parameter
10:15 < sipa> hmm, never realized that this reasoning leads to an odd [lower subsidy] -> [high exchange rate] relation
10:15 < sipa> which is probably not true in practice
10:16 < bramc> sipa, I expect bitcoin prices to spike after the next time mining rewards halve, which will be in early 2016
10:16 -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards
10:16 < sipa> bramc: approximately nothing happened the previous time
10:17 < sipa> (which is not to say you're wrong, but i wouldn't bet on it myself)
10:17 < bramc> sipa, There was a lot less pro mining going on last time. I could of course be wrong.
10:17 < bramc> Not sure I'll bet on it either :-)
10:17 < sipa> well if you do, now may be the time to buy :D
10:18 < bramc> No, there's way too much volatility in bitcoin for it to make sense to buy now based on a movement expected a year from now
10:18 < sipa> fair enough; i was only joking
10:19 < bramc> The price of bitcoin dropping is good for the environment
10:19 < sipa> and bad for its security :)
10:19 < bramc> although the relation may not be very immediate and linear because of all the sunk costs into hardware
10:20 -!- adam3us [~Adium@host-92-18-104-28.as13285.net] has quit [Read error: Connection reset by peer]
10:21 -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Ping timeout: 250 seconds]
10:21 -!- adam3us [~Adium@host-92-18-104-28.as13285.net] has joined #bitcoin-wizards
10:21 < bramc> That said, all this stuff I've been working out is very interesting and worth publishing regardless
10:22 < fluffypony> sipa: why bad for tis security?
10:22 < fluffypony> *its
10:22 -!- tacotime [~mashkeys@198.52.200.63] has quit [Ping timeout: 245 seconds]
10:23 < bramc> Nobody seems curious about my super cute idea of how to adjust work difficulty when you're mixing both proofs of time and proofs of work
10:23 < sipa> what is proof of time?
10:23 < fluffypony> sipa: Proof of DeLorean
10:23 -!- Dizzle [~diesel@207.11.113.29] has joined #bitcoin-wizards
10:23  * sipa gets his Mr. Fusion
10:24 < bramc> A proof of time is an operation which has to be done sequentially, and where a short proof results in the end which is much quicker to verify than to re-do the entire set of work
10:24 < sipa> non-parallellizable proof-of-work, basically?
10:25 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection]
10:25 < bramc> If you make them alternate with proofs of work in a block chain you can force everything to sit around doing nothing a substantial fraction of the time, which disadvantages custom hardware because it gets killed by depreciation vs. hardware which was already acquired for other reasons and is sitting around depreciating
10:25 < sipa> fluffypony: what if i tried to send a 1G dollar transaction in bitcoin?
10:25  * fluffypony blanks out
10:25 < fluffypony> 1G?
10:25 < sipa> 1 billion
10:25 < fluffypony> oh
10:26 < fluffypony> good point
10:27 < bramc> sipa, Yes exactly, non-parallelizable
10:27 < sipa> bramc: can you keep that progress-free?
10:28 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards
10:28 < bramc> define 'progress-free'
10:29 < bramc> It's possible to make a proof of time be dependent on an external value and non-interactive
10:29 < bramc> It isn't at all obvious that this is possible. This paper gives a construction, which I've figured out some big improvements on: https://eprint.iacr.org/2011/553.pdf
10:30 -!- orik [~orik@c-71-231-78-253.hsd1.wa.comcast.net] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
10:31 < bramc> So if by 'progress-free', you mean that it has to be started from scratch after each block, then yes that's totally doable, although there's some fun crypto involved
10:33 -!- grandmaster [dansmith3@knows.the.cops.are.investigat.in] has quit [Remote host closed the connection]
10:34 < bramc> Maybe the issue isn't that people aren't curious about my idea but that I haven't clearly explained the problem
10:34 -!- wserd [c18adbea@gateway/web/cgi-irc/kiwiirc.com/ip.193.138.219.234] has joined #bitcoin-wizards
10:36 < gmaxwell> bramc: what you're talking about is very much the opposite of progress free (in something progress free, a faster party doesn't have a disproportiate advantage. Non-progress free is like a race, the fastest always wins). But I think it's not really applicable for your goal, which indeed you haven't explained there.
10:37 < sipa> while progress-free is a lottery
10:38 < bramc> gmaxwell, Okay then it's totally progress-full, the idea being that almost everybody has about the same max clock speed, so a handful of ridiculously overclocked honesty servers will do that proofs of time while everybody else sits around and waits for it.
10:38 < sipa> you turn it into a fastest-sequential-hardware-always-wins
10:38 < bramc> I call them 'honesty' servers because there's no direct reward for finding the proofs of time. It can give you a bit of a jump on mining though, as long as someone else isn't playing the same game better
10:38 < sipa> basically
10:38 < nsh> i'm not sure anyone is able to prove clock-cycles-dedicated-to-P for any problem
10:38 < bramc> sipa, Yes exactly, and the differences there tend to be small, and the protocol is design so there isn't actually a reward for that step
10:40 < bramc> nsh, The paper I just linked does, and it's possible to improve on that one quite a bit. It doesn't involve any particularly complicated crypto, just hashing used in a clever way
10:41 < gmaxwell> bramc: does it do anything at all then? e.g. if you are not rewarded in the protocol for doing it, but it does something,  can you just do it evily and actually get a reward?
10:41 < bramc> So my idea is that the block chain should alternate between proofs of work (blocks) and proofs of time, and each one refers to the previous one, so it's enforced that time was spent between mining operations
10:41 < AdrianG> hm.
10:41 < gmaxwell> For example, no one pays you for it normally. But someone wants to go mine a fork and to do that they need it done, so why not just abandon the honest network and go mine the fork where your costly sequential hardware will get paid for?
10:41 < bramc> gmaxwell, If you set up a superoverclocked setup you can start mining the next block before everybody else does
10:41 -!- tacotime [~mashkeys@198.52.200.63] has joined #bitcoin-wizards
10:42  * nsh reads linked paper :)
10:42 < gmaxwell> bramc: that goal sounds like its a non-trivial centeralization advantage even if it does what you want, then?
10:43 < bramc> gmaxwell, You're hinting at the really interesting question: How should the work difficulty of the proofs of time and proofs of work be adjusted if you want to maintain a specific ratio between them regardless of the current scale of each?
10:43 < nsh> consideration of scale: good -- tweaking: bad
10:43 < bramc> gmaxwell, it winds up having some centralization in an interesting way. There are a handful of overclocked honesty servers who publish their time proofs to keep the others from getting an advantage
10:44 < bramc> nsh, not sure what you mean
10:44 -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has quit [Ping timeout: 264 seconds]
10:44 < nsh> you don't want a strong-dependence on (human) fine-tuning
10:45 < nsh> and network-level adaptation has a pretty limited remit at the moment
10:45 -!- tacotime [~mashkeys@198.52.200.63] has quit [Remote host closed the connection]
10:45 -!- tacotime [~mashkeys@198.52.200.63] has joined #bitcoin-wizards
10:46 < bramc> gmaxwell, Hopefully even the extremely overclocked honesty servers aren't really much faster than the handful of slower people running honesty servers just in case, and you can't get too aggressive about how much of the time is spent in proofs of time vs proofs of work or an overclocker has too much potential advantage, maybe 2:1 is reasonable
10:47 < bramc> nsh, bitcoin's work adjustment works just fine
10:47 < nsh> bramc, are you improvements to the depth-robust DAG-based sequential hashes public?
10:47 < bramc> nsh, no not public yet
10:47 < nsh> bramc, that's because it does one very limited thing where getting it wrong just minorly inconveniences people
10:47 < nsh> :)
10:47 < bramc> And it isn't exactly a DAG any more. I found another tirck :-)
10:47 < nsh> neat
10:47 < pigeons> trust me, i'm an honesty server
10:48 < nsh> (by getting it wrong i mean over- or underadjustice-adjusting a little, not failing to prevent hashpower attacks)
10:48 < nsh> *unmangle
10:49 -!- MoALTz [~no@user-164-126-31-182.play-internet.pl] has joined #bitcoin-wizards
10:49 < bramc> nsh, Yes the interesting question is how you handle having two different types of work and trying to maintain an appropriate ratio between them, and this is where I have an interesting/crazy idea
10:51 < nsh> (also quite a few factors make the recalculation of target consensuable: based on public information, limited leeway to skew the adjustment by lying about timestamps, everyone can verify it was performed soundly, it's as trivial as it can be with the desired control properties)
10:51 < bramc> Yes that's the problem: You don't want to rely on timestamps
10:52 < bramc> The only timestamping you have any confidence in is the difference across reset intervals
10:53 < nsh> what's a reset, sorry?
10:53 < bramc> When the difficulty of mining operations is changed, I'm not sure what that's called
10:54 < nsh> retarget, i guess
10:54 < gmaxwell> retargeting, yep.
10:54 < nsh> but yeah, that is the network-level tick
10:54 < nsh> (blocks can be considered elastic subdivisions between ticks, i suppose...)
10:55 < bramc> Right, so you have exactly one thing you can rely on for retargeting, which is the amount of time spent over an interval, because anyone getting a block chain can look at the time and compare the total rewards given in the chain to the total rewards which should have been handed out by now and reject if it they're too much (technically it doesn't do exactly that, but this is the essence of what is happening)
10:57 < nsh> (the bitcoin network is statistically measuring energy-expended as a proxy of time based on a measuring of power)
10:57 -!- zooko [~user@c-71-229-205-98.hsd1.co.comcast.net] has joined #bitcoin-wizards
10:57 < nsh> (which works out to be roughly equivalent to measuring time, but not in the same way as you're considering proof-of-time through sequential hashing)
10:58 < bramc> Right, you have an apple-to-peanuts problem with proofs of time vs. proofs of work
10:58  * nsh nods
10:59 -!- treehug88 [~treehug88@static-96-239-100-47.nycmny.fios.verizon.net] has quit []
10:59 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has joined #bitcoin-wizards
11:00 < bramc> So here's my crazy idea: Instead of having two work factors, one for each, you have a single composite work factor which is a combination of the two where the fastest way for everybody to collectively mine is to maintain the intended ratio
11:01 < bramc> Now mining operations and proofs of time are paired together, where a mining operation isn't considered to be successful until the proof of time after it has hit the appropriate threshold
11:02 -!- treehug88 [~treehug88@static-96-239-100-47.nycmny.fios.verizon.net] has joined #bitcoin-wizards
11:03 < nsh> and the ratio would retarget globally at some interval based on a function of the network sums of each rates over the prior interval?
11:03 < bramc> The exact formula you use depends on the ratio you're trying to enforce. The key observation for coming up with the formula is that both proofs of work and proofs of time have the property that you can do twice as much in twice as much time, and that you want the formula to be scale free, meaning regardless of the current scale twice as much time will result in double the value
11:03 < bramc> No the ratio is set, it doesn't move
11:04 < nsh> then what truth does it encode?
11:04 < bramc> You have to decide beforehand that, for example, you want there to be twice as much time spent in proofs of time as proofs of work
11:04 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds]
11:05 < bramc> And that ratio will be enforced by the formula, at least if people are mining as efficiently as they possibly can
11:05 < nsh> it would surprise me (moderately) if there was a platonic constant that represented some eternal truth about the relationship between parallelizable and sequential work independent of today's contingent stage of human electronic technological sophistication
11:06 < nsh> but there could be a sweet spot, i guess
11:06 < nsh> or does the ratio reflect something else?
11:06  * nsh is probably missing things
11:07 < bramc> Not sure what you mean. The nature of time isn't going to change any time soon. What's being enforced is that the system spends six minutes in proof of time, then three in proof of work, then six in time, then three in work, etc.
11:07 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection]
11:08 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards
11:08 < nsh> you can't prove an alternating sequence between things where only one is inherently sequential
11:08 < nsh> (i claim)
11:09 < nsh> you can prove state dependency though
11:09 < kanzure> "nature of time isn't going to change any time" i get it
11:10 -!- jasonw22 [~jasonw22@208.74.176.33.static.etheric.net] has quit [Quit: Lingo: www.lingoirc.com]
11:10 -!- vmatekole [~vmatekole@p5DC478FC.dip0.t-ipconnect.de] has quit [Ping timeout: 265 seconds]
11:10 < bramc> Still not sure what you mean. The blockchain format itself is fairly straightforward, and can in fact prove what's claimed, at least in terms of the *number* of sequential steps which happened, the nuance is in how much *time* they took
11:10 < nsh> right
11:10 < bramc> It isn't terribly obvious that it's possible to make proofs of time which work this way, but for the sake of current discussion I'd like to just assume it is because that's a very long tangent
11:12 < bramc> So here's my idea: Let's say that we want to spend an equal amount of time in both. There's a single work factor which needs to be met for a proof of work and its following proof of time to be valid. The formula is (W*T)^(1/2)
11:12 < nsh> so it's kind of lock-step march arrangement? the PoW worker must wait for the (cryptographically-verifiably) correct answer from PoT / seq.hashing worker to get some value that it can grind?
11:12 < nsh> and then vice versa?
11:12 < bramc> Yes exactly, it's alternating
11:12 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Ping timeout: 256 seconds]
11:12 < nsh> right, i had similar ideas for maintaining (granular) progress-freeness while being tied to some relatively-arbitrary "useful" ancillary calculation
11:13 < nsh> proving sequential operation being a particular case of useful
11:14 -!- jasonw22 [~jasonw22@208.74.176.33.static.etheric.net] has joined #bitcoin-wizards
11:15 < bramc> The way that formula works out is that when someone is doing a proof of work they have to decide what work factor they're shooting for before they start, and they'll naturally be incented to set the amount of work they're shooting for be the one which will make the rewards happen as soon as possible
11:15 < nsh> so with the left foot you're sacrificing progress-freeness and decentralization, but the right foot you're clawing it back
11:15 < nsh> the optimum ratio is like ensuring your left leg and right leg are the same length
11:16 < nsh> it's naturally incentivized
11:16 < bramc> Yes you can view it that way
11:17 < nsh> i still think it's not going to be constant enough, but it might not matter badly
11:17 < bramc> It's also possible to set other ratios, for example if you want to spend twice as much time in time as work you can use (W*T^2)^(1/3)
11:18 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards
11:19 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection]
11:19 < nsh> has to be the case that the baton being passed between the two types of work -- the state-information each requires to resume -- is tied to that node, and can't be networked
11:19 < nsh> otherwise i think you can game it
11:19 < nsh> (tied to previous work done by that node)
11:20 < nsh> markelwhatever
11:20 < bramc> Each proof directly references the previous one by hash, so the primitives being used enforce that
11:20  * nsh nods
11:20 < bramc> It's a good idea to force proofs of work to declare what they're shooting for up front though
11:21 < bramc> Or maybe not. I need to think about that one
11:21 < nsh> well, it must be validatable by any full node
11:21 < bramc> Yeah, validation is easy (well, assuming the proof of work thing is done right, which isn't trivial but is doable)
11:22 < bramc> Unfortunately the proofs of time are a bit big, like 100k-150k
11:22 < bramc> I meant 'the proof of time thing is done right' not 'the proof of work thing is done right'
11:22  * nsh nods
11:22 -!- lclc is now known as lclc_bnc
11:22 < bramc> They can in principle be made much smaller using zero knowledge proofs, but that's impractical at current computation scale
11:23 < nsh> poly(n). polylog(N).  for verifying mahmoody's construction
11:24 < bramc> I've got it down to log(n)*log(n)
11:24 < bramc> That is, log(n) for the construction, log(n) for the number of samples you do
11:25 < nsh> neat
11:26 < bramc> I now have a list of papers I need to write. I feel like I should enroll in a PhD program.
11:26  * nsh smiles
11:27 -!- belcher [~belcher-s@unaffiliated/belcher] has joined #bitcoin-wizards
11:27 < bramc> And I still have a huge pile of things to work through and need to figure out what I'm actually going to build
11:35 -!- Profreid [~Profreitt@179.43.134.2] has joined #bitcoin-wizards
11:36 -!- Dizzle [~diesel@207.11.113.29] has quit [Quit: brb]
11:36 -!- Dizzle [~diesel@70.114.207.41] has joined #bitcoin-wizards
11:45 -!- zooko [~user@c-71-229-205-98.hsd1.co.comcast.net] has quit [Ping timeout: 264 seconds]
11:53 -!- grau [~grau@37.143.74.116] has quit [Remote host closed the connection]
11:53 -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards
12:00 -!- austinhill [~Adium@bas11-montrealak-1177755981.dsl.bell.ca] has joined #bitcoin-wizards
12:00 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has joined #bitcoin-wizards
12:00 -!- Burrito [~Burrito@unaffiliated/burrito] has joined #bitcoin-wizards
12:05 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds]
12:05 -!- austinhill [~Adium@bas11-montrealak-1177755981.dsl.bell.ca] has quit [Ping timeout: 250 seconds]
12:11 -!- [d__d] [~d__d]@23.253.33.192] has quit [Remote host closed the connection]
12:13 -!- [d__d] [~d__d]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-wizards
12:16 -!- Profreid [~Profreitt@179.43.134.2] has quit [Quit: Profreid]
12:22 -!- ryanxcharles [~ryanxchar@162-245-22-162.v250d.PUBLIC.monkeybrains.net] has quit [Ping timeout: 258 seconds]
12:24 < tdlfbx> Can anyone suggest any use case for allowing the pubkeys in a multisig address to occur in different orders (for the same set of pubkeys)?  e.g. allowing different addresses for the same set of keys.
12:25 < sipa> not really, but i also don't see much use case for enforcing an order
12:25 < sipa> the spenders need to know the exact redeemscript anyway
12:25 < tdlfbx> reducing confusion.
12:26 < sipa> yeah, i understand, it means you can reconstruct the redeemscript from just the involved public keys
12:26 < tdlfbx> Just to specify a standard, for software interoperability.
12:26 < sipa> but public keys are not generally something that is transferred independently anyway
12:26 < gmaxwell> tdlfbx: you can reduce confusion with standards instead of enforcement though. :)
12:26 < sipa> i'm sure that's what he's proposing
12:26 < tdlfbx> gmaxwell: I agree.  I'm thinking of writing a BIP.
12:27 < belcher> order them in ascending order?
12:27 < gmaxwell> belcher: which ascending order? there are several.
12:27 < tdlfbx> I'm unsure whether enforcing it in future transactions is necessary or useful.
12:27 < sipa> i'm not opposed but i think it is 1) way to late and 2) not really useful
12:27 < tdlfbx> sipa: why is it way too late?  As long as existing transactions aren't invalidated...
12:27 < sipa> also, #bitcoin-dev
12:27 < sipa> tdlfbx: why would anyone adopt it?
12:27 < gmaxwell> tdlfbx: it would be useful to do in the context of anything that proposes an encoding for sending around data, at least.
12:28 < tdlfbx> Every time I ask any question in any channel, someone tries to send me to a different channel.
12:28 < sipa> well you're talking about bitcoin, this channel isn't
12:28 -!- RoboTeddy [~roboteddy@2604:5500:13:5fc:803b:ab15:d0f5:696d] has joined #bitcoin-wizards
12:29 < tdlfbx> Why would anyone adopt it?  If two software vendors/projects want to both do multisig, and be compatible with each other, give them a BIP to point to to decide this.
12:31 < gmaxwell> tdlfbx: compatible in which respect though?  e.g. what messages would be communicated between them where an incompatiblity might arise?
12:31 < gmaxwell> (and why wouldn't that message specify an ordering if it was helpful there?)
12:32 < bramc> Is there a string order comparator which can be used in redeemscripts?
12:32 < tdlfbx> gmaxwell: It could.  This is trivial to solve really.  But different implementors will make different choices.
12:32 < sipa> please
12:34 -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has joined #bitcoin-wizards
12:36 -!- Profreid [~Profreitt@179.43.133.98] has joined #bitcoin-wizards
12:38 -!- ryanxcharles [~ryanxchar@162-245-22-162.v250d.PUBLIC.monkeybrains.net] has joined #bitcoin-wizards
12:47 -!- atgreen [user@nat/redhat/x-qalpztqvcxkbtmwa] has joined #bitcoin-wizards
12:48 -!- MoALTz [~no@user-164-126-31-182.play-internet.pl] has quit [Quit: Leaving]
12:55 < bramc> How much of a problem is dust really? Do wallets in the wild wind up getting filled with dust?
12:56 < fluffypony> yes
12:57 < fluffypony> if you're pool mining with a smallish piece of hardware, of course
12:58 < bramc> How small does the dust tend to be compared to the size of the account? 1%? .1%?
12:59 < Luke-Jr> fluffypony: pools tend to offer minimum payouts to avoid that
13:00 < fluffypony> Luke-Jr: sure, so it depends on what you define as dust
13:00 < fluffypony> and you're a piss-poor reference point for that, given your history.
13:00 < Luke-Jr> lolwut, are you trolling?
13:00 < fluffypony> Luke-Jr: no off-topic, plx.
13:00 < Luke-Jr> …
13:01 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has joined #bitcoin-wizards
13:04 < bramc> When wallets pay out, do they always hand out one utxo or do they sometimes hand over a bunch of utxos whole to avoid extra linking?
13:05 -!- ryanxcharles [~ryanxchar@162-245-22-162.v250d.PUBLIC.monkeybrains.net] has quit [Ping timeout: 258 seconds]
13:05 -!- CoinMuncher [~jannes@178.132.211.90] has quit [Quit: Leaving.]
13:06 < Luke-Jr> bramc: Bitcoin Core always does one, but multiple may become more common in the future
13:06 < Luke-Jr> it's been discussed, at least - not sure if any other wallet is implementing it yet
13:06 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has quit [Ping timeout: 265 seconds]
13:06 < Luke-Jr> since each UTXO needs its own address, it only really works with things like stealth addresses
13:06 < sipa> Luke-Jr: i have an email from satoshi from 2011 in which he suggests doing that :)
13:07 < bramc> multiple seems like a good idea, no need to go shmearing the history of everybody else you've done business with across the block chain
13:07 < belcher> satoshi was still around in 2011 ?
13:07 < sipa> belcher: not publicly
13:07 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards
13:07 < belcher> i know, last post around 2010
13:07 < sipa> it was early 2011
13:10 < bramc> not sure what you mean by 'stealth addresses'. Obviously you need to send multiple utxos to different recipient keys or there's no point
13:11 -!- grau [~grau@37.143.74.116] has joined #bitcoin-wizards
13:11 < sipa> stealth addresses are a sort of static address that lets the sender derive the actual key at sending time, and attaches data to the transaction to make it recoverable by the receiver
13:12 < sipa> so every transaction on the chain pays to a different key, even though the identifier used was the same
13:12 -!- grau [~grau@37.143.74.116] has quit [Remote host closed the connection]
13:13 < Muis> Monero does something very similar as stealth adresses
13:18 < bramc> Are these explained in bip32 or is that something else?
13:19 -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has joined #bitcoin-wizards
13:20 -!- nubbins` [~leel@unaffiliated/nubbins] has joined #bitcoin-wizards
13:21 < fluffypony> Muis: kinda...we have two public keys, and the "destination" for an output is computed from both of those pubkeys + some random data
13:24 -!- jtimon_ [~quassel@127.pool85-53-130.dynamic.orange.es] has joined #bitcoin-wizards
13:24 < Muis> bramc: http://sx.dyne.org/stealth.html
13:25 < bramc> Thanks Muis
13:26 < fluffypony> (computed by P = Hs(rA)G+B, where P = one-time public key / destination, Hs = a hashing function, r = a random r ∈ [1,l-
13:28 -!- atgreen [user@nat/redhat/x-qalpztqvcxkbtmwa] has quit [Remote host closed the connection]
13:29 -!- jtimon [~quassel@145.pool85-53-220.dynamic.orange.es] has quit [Ping timeout: 272 seconds]
13:37 -!- bifforoni [~zorin@bzq-84-108-84-113.cablep.bezeqint.net] has quit [Quit: Leaving]
13:40 -!- aburan28 [~ubuntu@static-108-45-93-73.washdc.fios.verizon.net] has joined #bitcoin-wizards
13:40 -!- adam3us [~Adium@host-92-18-104-28.as13285.net] has quit [Quit: Leaving.]
13:43 -!- grau [~grau@37.143.74.116] has joined #bitcoin-wizards
13:44 -!- NewLiberty_ [~NewLibert@76-255-129-88.lightspeed.irvnca.sbcglobal.net] has quit [Quit: Leaving]
13:47 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye]
13:48 -!- grau [~grau@37.143.74.116] has quit [Ping timeout: 265 seconds]
13:48 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:3db5:f6f7:d6e2:13b7] has joined #bitcoin-wizards
13:48 -!- NewLiberty_ [~NewLibert@2602:304:cff8:1580:3db5:f6f7:d6e2:13b7] has joined #bitcoin-wizards
13:48 -!- NewLiberty__ [~NewLibert@2602:304:cff8:1580:3db5:f6f7:d6e2:13b7] has joined #bitcoin-wizards
13:48 < AdrianG> is anyone interested in analyzing bitcoin's incentive structure?
13:49 < tdlfbx> AdrianG: people talk about little else.
13:49 < AdrianG> i dont see that.
13:49 < tdlfbx> stick around.  ;-)
13:50 < AdrianG> bramc: why do you expect 2016 halvening will have any serious impact on btc market cap at all?
13:51 < AdrianG> only because instead of 3.6k, we'll have 1.8k new coins entering markets daily?
13:51 < bramc> AdrianG, If miners are selling their coins as they get them the supply of coins available will immediately tank
13:51 < bramc> Yep
13:51 < AdrianG> bramc: everyone knows when it'll happen, it's going to be priced in well before it actually happens.
13:52 < AdrianG> exchange volumes are way higher than 3.6k.
13:52 < AdrianG> this makes sense in theory, I don't know how applicable this is in practice.
13:52 < bramc> AdrianG, Maybe. We shall see. there's enough uncertainty that it's hard for the market to prepare
13:52 < AdrianG> for now, it is too far away, yes.
13:53 < bramc> It's also possible that the price will rise in advance expecting a spike and then drop right after when the spike doesn't happen
13:53 < AdrianG> but think of it in a different way. if btc market cap goes to 100+ billions, it'll cost 6.5 billion/year to secure the network after 2016
13:53 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards
13:53 < AdrianG> 6.5 bn/year. thats seriously high costs.
13:54 -!- NewLiberty__ [~NewLibert@2602:304:cff8:1580:3db5:f6f7:d6e2:13b7] has quit [Quit: Leaving]
13:54 -!- NewLiberty_ [~NewLibert@2602:304:cff8:1580:3db5:f6f7:d6e2:13b7] has quit [Quit: Leaving]
13:54 < bramc> AdrianG, Yes that's the sucky thing about cryptocurrencies
13:55 < AdrianG> I think that's a very serious hurdle.
13:55 -!- ompik [~snoek@li578-62.members.linode.com] has joined #bitcoin-wizards
13:56 < tdlfbx> How much do we spend on banks now though?
13:57 < AdrianG> tdlfbx: for sure inflation and the "banking" cartel end up costing more.
13:57 < AdrianG> but nobody percieves those costs as actual "costs"
13:57 < tdlfbx> And the bankers love that.
13:57 < AdrianG> i know an argentinian who was screwed out of his retirement nest egg by the arg. govt
13:57 < AdrianG> he went as far as immigrating to another state, starting a new life
13:58 < AdrianG> and now guess what, he keeps voting for bigger govts.
13:58 < AdrianG> tdlfbx: of course they love it, its the best scam on earth.
13:58 -!- grau [~grau@37.143.74.116] has joined #bitcoin-wizards
13:58 < AdrianG> however, this doesnt resolve the economic issues the blockchain will run into if it grows.
13:58 -!- wserd [c18adbea@gateway/web/cgi-irc/kiwiirc.com/ip.193.138.219.234] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
13:59 < AdrianG> the technology can easily be resolved, even if it requires terabytes of storage and lots of 24/7 bandwidth. I'm not sure how economics are going to be solved, if at all, I don't think anyone will seriously consider altering reward schedules.
13:59 < tdlfbx> PoW is like democracy.  It's the best of a bad lot.  Yes it's expensive.  But there's no alternative.
14:00 < AdrianG> on the other hand, coins sold by miners offer constant liquidity.
14:00 < AdrianG> so its not like its a total negative.
14:01 < bramc> I don't mean to be one of those people, but could we not have this discussion on this channel?
14:01 -!- wserd [2ea5e477@gateway/web/cgi-irc/kiwiirc.com/ip.46.165.228.119] has joined #bitcoin-wizards
14:01 -!- grau [~grau@37.143.74.116] has quit [Remote host closed the connection]
14:02 < AdrianG> the cost considerations?
14:02 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has joined #bitcoin-wizards
14:03 < bramc> AdrianG, the political angle. Technical discussions of the implications of cost structure I'm happy to engage in
14:04 < AdrianG> i dont care much for political talk either.
14:04 < AdrianG> but anyway.
14:04 < AdrianG> at that size of blockchain, costs to secure it will pretty much equal operating income of the UK's National Grid PLC
14:05 < bramc> The hard limit on transaction volume is likely to be a big problem long before then
14:05 < AdrianG> thats a technical problem, and can be solved, i think
14:06 < bramc> It isn't a terribly simple thing to solve
14:06 -!- aburan28 [~ubuntu@static-108-45-93-73.washdc.fios.verizon.net] has quit [Ping timeout: 245 seconds]
14:06 -!- Profreid [~Profreitt@179.43.133.98] has quit [Quit: Profreid]
14:06 -!- hashtag [~hashtag@cpe-98-157-219-44.ma.res.rr.com] has quit [Ping timeout: 255 seconds]
14:06 < AdrianG> ofc not, but it can be solved.
14:07 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds]
14:07 < bramc> It's also possible that more utxos might get to be 'in circulation' at larger scale, and the price would go down correspondingly. The vast majority have never been spent.
14:07 < AdrianG> bramc: i think thats whats happening at the moment
14:08 < bramc> It's quite likely that someone, maybe, I dunno, the winklevoss twins, is buying up coins whenever the price drops too much to prevent a fast selloff, but they might have run out of cash
14:08 < AdrianG> tbh, at that size, thats M1 money supply of smaller states, like finland and singapore
14:09 < bramc> It isn't clear how much real commerce is happening via bitcoin right now. It's possible that the overwhelming majority is still speculation.
14:09 < AdrianG> most certainly it is specs.
14:10 < bramc> As a general rule an unfounded asset can go down just as quickly as it went up
14:10 < AdrianG> btc is basically a foreign currency. even if you'd have blockchain based, idk, yuans
14:10 < AdrianG> why would anyone use them in the US? exchange costs/volatility alone would be a major issue.
14:11 < bramc> If you want expedient money transfers. They actually cost less than western union.
14:11 < AdrianG> cross-border - yes, its great
14:11 < AdrianG> which is where i expect to gain traction first
14:11 < AdrianG> it already did, in some ways.
14:12 < bramc> Of course, there's nothing stopping the traditional banking system from getting its shit together and offering a similar service, which wouldn't be a bad thing
14:13 < AdrianG> http://en.wikipedia.org/wiki/Fortum
14:14 < AdrianG> so basically yes, bitcoin mining will have to become a large utility corp to support marketcaps of that size
14:14 < AdrianG> do you think its actually feasible?
14:15 < bramc> Probably not, but I'm just working on interesting engineering problems
14:15 < AdrianG> which?
14:16 < bramc> And honestly, my attitude towards people 'investing' in bitcoin by buying it is caveat emptor
14:16 -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has quit [Quit: Leaving]
14:17 < bramc> AdrianG, There's been a whole long list of interesting technical discussions about bitcoin I've been having on here, still not sure what I'm going to build though
14:17 -!- grau [~grau@37.143.74.116] has joined #bitcoin-wizards
14:17 < AdrianG> are PoS/hybrid/etc sidechains possible theoretically?
14:18 -!- grau [~grau@37.143.74.116] has quit [Remote host closed the connection]
14:20 < bramc> In principle scaling issues could be addressed with sidechains. It isn't a slam dunk though.
14:21 < AdrianG> yes, but can they be using anything else besides PoW
14:22 < AdrianG> ?
14:22 < bramc> Someone else needs to explain all the details of how microtransactions can be enabled via sidechains. I remain skeptical.
14:23 < AdrianG> with microtransactions its the 1st time sign up thats the cause of friction
14:24 -!- grau [~grau@37.143.74.116] has joined #bitcoin-wizards
14:24 < bramc> It isn't the case that mining has to be a particular fraction of transaction volume by the way. All that has to happen is that it's more profitable to take mining rewards and transaction fees than to engage in fraudulent double-spending. It's rather hard to do fraudulent double-spending, and if it starts getting dicey then the likely result is that people will just have to wait longer for transactions to clear
14:24 < bramc> because what matters is the total amount of work which has passed since your transaction went through, so waiting longer works well.
14:25 < AdrianG> bramc: do you really think microtxns need to be secured by the entire network
14:25 < bramc> There are a lot of problems with microtransactions. The biggest one being blowing the transaction rate limit.
14:25 -!- grau [~grau@37.143.74.116] has quit [Remote host closed the connection]
14:25 < bramc> the output of a microtransaction needs to be redeemable, that's where the problems come in
14:25 < AdrianG> even securing $4 starbuck coffees sounds absurd
14:26 < bramc> Well buying at point of sale has the problem that it takes half an hour for a transaction to clear
14:27 < AdrianG> exactly, so its a non-starter
14:27 < AdrianG> they are going to be centralized, like changetip or something
14:27 < bramc> or VISA :-P
14:29 < bramc> sidechains could possibly have shorter clearing times, but getting under 30 seconds presents some deep engineering challenges
14:30 < AdrianG> ive heard someone proposing multisig txns for those scenarios
14:30 < AdrianG> with one of them being basically a bank of sorts, like coinbase cosigns your transactions, etc
14:33 -!- instagibbs [32f65962@gateway/web/freenode/ip.50.246.89.98] has joined #bitcoin-wizards
14:33 < instagibbs> GA.it is exactly such an arrangement. 2-of-2, GA.it promises not to double-spend.
14:33 -!- wserd [2ea5e477@gateway/web/cgi-irc/kiwiirc.com/ip.46.165.228.119] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
14:35 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye]
14:35 -!- OneFixt_ [~OneFixt@unaffiliated/onefixt] has joined #bitcoin-wizards
14:36 -!- bitbumper [~bitbumper@161.47.143.24.cm.sunflower.com] has joined #bitcoin-wizards
14:36 -!- orik [~orik@c-71-231-78-253.hsd1.wa.comcast.net] has joined #bitcoin-wizards
14:37 < AdrianG> ?
14:37 < AdrianG> GA?
14:38 -!- ryanxcharles [~ryanxchar@162-245-22-162.v250d.PUBLIC.monkeybrains.net] has joined #bitcoin-wizards
14:38 < instagibbs> GreenAddress.it (GA.it)
14:38 -!- OneFixt [~OneFixt@unaffiliated/onefixt] has quit [Ping timeout: 250 seconds]
14:38 < instagibbs> sorry it's a long name
14:39 -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has joined #bitcoin-wizards
14:40 < instagibbs> hub-spoke style micropayment channels make even more sense. Similar limited trust model, most activity "off-chain"
14:50 -!- nubbins` [~leel@unaffiliated/nubbins] has quit [Quit: Quit]
14:52 -!- wserd [52c05fb8@gateway/web/cgi-irc/kiwiirc.com/ip.82.192.95.184] has joined #bitcoin-wizards
14:53 -!- wserd [52c05fb8@gateway/web/cgi-irc/kiwiirc.com/ip.82.192.95.184] has quit [Client Quit]
14:56 -!- grau [~grau@37.143.74.116] has joined #bitcoin-wizards
14:57 -!- instagibbs [32f65962@gateway/web/freenode/ip.50.246.89.98] has quit [Quit: Page closed]
14:58 -!- treehug8_ [~treehug88@66.6.34.255] has joined #bitcoin-wizards
14:58 -!- wserd [5fd3c501@gateway/web/cgi-irc/kiwiirc.com/ip.95.211.197.1] has joined #bitcoin-wizards
14:58 -!- mkarrer [~mkarrer@135.Red-83-52-38.dynamicIP.rima-tde.net] has joined #bitcoin-wizards
15:00 -!- tacotime [~mashkeys@198.52.200.63] has quit [Ping timeout: 256 seconds]
15:00 -!- wallet421 [~wallet42@g225012206.adsl.alicedsl.de] has joined #bitcoin-wizards
15:00 -!- prodatalab_ [~prodatala@c-69-254-45-177.hsd1.fl.comcast.net] has joined #bitcoin-wizards
15:00 -!- wallet421 [~wallet42@g225012206.adsl.alicedsl.de] has quit [Changing host]
15:00 -!- wallet421 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards
15:00 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Killed (cameron.freenode.net (Nickname regained by services))]
15:00 -!- wallet421 is now known as wallet42
15:00 -!- grau [~grau@37.143.74.116] has quit [Ping timeout: 258 seconds]
15:02 -!- austinhill [~Adium@bas11-montrealak-1177755981.dsl.bell.ca] has joined #bitcoin-wizards
15:03 -!- nullbyte [~WW@cpe-66-68-54-206.austin.res.rr.com] has joined #bitcoin-wizards
15:03 -!- nullbyte [~WW@cpe-66-68-54-206.austin.res.rr.com] has quit [Changing host]
15:03 -!- nullbyte [~WW@unaffiliated/loteriety] has joined #bitcoin-wizards
15:03 -!- c0rw1n [~c0rw1n@174.179-67-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 245 seconds]
15:03 -!- ebfull [~ebfull@c-76-120-40-34.hsd1.co.comcast.net] has quit [Ping timeout: 245 seconds]
15:03 -!- treehug88 [~treehug88@static-96-239-100-47.nycmny.fios.verizon.net] has quit [Ping timeout: 245 seconds]
15:03 -!- mkarrer_ [~mkarrer@135.Red-83-52-38.dynamicIP.rima-tde.net] has quit [Ping timeout: 245 seconds]
15:03 -!- prodatalab [~prodatala@c-69-254-45-177.hsd1.fl.comcast.net] has quit [Ping timeout: 245 seconds]
15:05 -!- wserd [5fd3c501@gateway/web/cgi-irc/kiwiirc.com/ip.95.211.197.1] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
15:06 -!- c0rw1n [~c0rw1n@174.179-67-87.adsl-dyn.isp.belgacom.be] has joined #bitcoin-wizards
15:06 -!- austinhill [~Adium@bas11-montrealak-1177755981.dsl.bell.ca] has quit [Ping timeout: 240 seconds]
15:07 -!- treehug8_ [~treehug88@66.6.34.255] has quit []
15:19 -!- MoALTz [~no@user-164-126-31-182.play-internet.pl] has joined #bitcoin-wizards
15:24 -!- cpacia [~chris@95.211.169.45] has joined #bitcoin-wizards
15:28 -!- wserd [5fd38811@gateway/web/cgi-irc/kiwiirc.com/ip.95.211.136.17] has joined #bitcoin-wizards
15:28 -!- Dizzle [~diesel@70.114.207.41] has quit [Quit: Leaving...]
15:35 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
15:38 -!- orik [~orik@c-71-231-78-253.hsd1.wa.comcast.net] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
15:45 -!- nessence [~alexl@178.19.221.38] has quit [Remote host closed the connection]
15:45 -!- nessence [~alexl@178.19.221.38] has joined #bitcoin-wizards
15:48 -!- nessence [~alexl@178.19.221.38] has quit [Read error: Connection reset by peer]
15:48 -!- nessence [~alexl@178.19.221.38] has joined #bitcoin-wizards
15:48 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving]
15:51 -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards
15:57 -!- Starduster [~guest@unaffiliated/starduster] has quit [Ping timeout: 240 seconds]
15:58 -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 240 seconds]
16:02 -!- nubbins` [~leel@unaffiliated/nubbins] has joined #bitcoin-wizards
16:04 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has joined #bitcoin-wizards
16:08 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
16:10 -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards
16:13 -!- grau [~grau@37.143.74.116] has joined #bitcoin-wizards
16:15 -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards
16:17 -!- grau [~grau@37.143.74.116] has quit [Remote host closed the connection]
16:17 -!- grau [~grau@37.143.74.116] has joined #bitcoin-wizards
16:18 -!- grau [~grau@37.143.74.116] has quit [Remote host closed the connection]
16:19 -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 255 seconds]
16:23 -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards
16:29 -!- sagara [835ebaa1@gateway/web/freenode/ip.131.94.186.161] has joined #bitcoin-wizards
16:29 -!- NikolaiToryzin [~stqism@freebsd/user/stqism] has joined #bitcoin-wizards
16:31 -!- OneFixt_ is now known as OneFixt
16:32 -!- nessence [~alexl@178.19.221.38] has quit []
16:34 -!- cpacia [~chris@95.211.169.45] has quit [Read error: Connection reset by peer]
16:34 -!- cpacia [~chris@95.211.169.45] has joined #bitcoin-wizards
16:38 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards
16:40 -!- RoboTeddy [~roboteddy@2604:5500:13:5fc:803b:ab15:d0f5:696d] has quit []
16:41 -!- belcher [~belcher-s@unaffiliated/belcher] has quit [Quit: Leaving]
16:42 -!- MoALTz_ [~no@user-164-126-31-182.play-internet.pl] has joined #bitcoin-wizards
16:42 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: This computer has gone to sleep]
16:45 -!- nubbins` [~leel@unaffiliated/nubbins] has quit [Quit: Quit]
16:45 -!- MoALTz [~no@user-164-126-31-182.play-internet.pl] has quit [Ping timeout: 250 seconds]
16:46 -!- Graftec [~Graftec@gateway/tor-sasl/graftec] has quit [Ping timeout: 250 seconds]
16:49 -!- RoboTeddy [~roboteddy@2604:5500:13:5fc:ec82:c562:3c50:188e] has joined #bitcoin-wizards
16:50 -!- Graftec [~Graftec@gateway/tor-sasl/graftec] has joined #bitcoin-wizards
16:52 -!- woah [~woah@162.217.74.107] has joined #bitcoin-wizards
16:53 -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 240 seconds]
16:53 -!- woah [~woah@162.217.74.107] has quit [Client Quit]
17:08 -!- ryanxcharles [~ryanxchar@162-245-22-162.v250d.PUBLIC.monkeybrains.net] has quit [Ping timeout: 250 seconds]
17:10 -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards
17:13 -!- sagara [835ebaa1@gateway/web/freenode/ip.131.94.186.161] has quit [Ping timeout: 246 seconds]
17:14 -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 255 seconds]
17:15 -!- tdlfbx [~bsm117532@172-0-174-200.lightspeed.cicril.sbcglobal.net] has quit [Remote host closed the connection]
17:17 -!- grau [~grau@37.143.74.116] has joined #bitcoin-wizards
17:19 -!- davejh69 [~davejh69@host86-185-124-238.range86-185.btcentralplus.com] has quit [Ping timeout: 264 seconds]
17:22 -!- grau [~grau@37.143.74.116] has quit [Ping timeout: 245 seconds]
17:23 -!- wserd [5fd38811@gateway/web/cgi-irc/kiwiirc.com/ip.95.211.136.17] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
17:24 -!- wserd [2530414c@gateway/web/cgi-irc/kiwiirc.com/ip.37.48.65.76] has joined #bitcoin-wizards
17:26 -!- manara [835ebaa1@gateway/web/freenode/ip.131.94.186.161] has joined #bitcoin-wizards
17:32 -!- mortale [~mortale@gateway/tor-sasl/mortale] has joined #bitcoin-wizards
17:33 -!- cpacia [~chris@95.211.169.45] has quit [Ping timeout: 258 seconds]
17:46 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 272 seconds]
17:52 -!- wserd [2530414c@gateway/web/cgi-irc/kiwiirc.com/ip.37.48.65.76] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
18:06 -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Remote host closed the connection]
18:12 -!- Starduster [~guest@unaffiliated/starduster] has joined #bitcoin-wizards
18:14 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
18:29 -!- prodatalab_ is now known as prodatalab
18:31 -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
18:34 -!- fanquake [~anonymous@unaffiliated/fanquake] has joined #bitcoin-wizards
18:35 -!- Dr-G3 [~Dr-G@gateway/tor-sasl/dr-g] has joined #bitcoin-wizards
18:35 -!- d1ggy_ [~d1ggy@dslb-092-076-018-081.092.076.pools.vodafone-ip.de] has joined #bitcoin-wizards
18:38 -!- Dr-G2 [~Dr-G@gateway/tor-sasl/dr-g] has quit [Ping timeout: 250 seconds]
18:39 -!- d1ggy [~d1ggy@dslb-092-077-202-004.092.077.pools.vodafone-ip.de] has quit [Ping timeout: 255 seconds]
18:41 -!- austinhill [~Adium@bas11-montrealak-1177755981.dsl.bell.ca] has joined #bitcoin-wizards
18:45 -!- Graftec [~Graftec@gateway/tor-sasl/graftec] has quit [Ping timeout: 250 seconds]
18:45 -!- austinhill [~Adium@bas11-montrealak-1177755981.dsl.bell.ca] has quit [Ping timeout: 265 seconds]
18:52 -!- Graftec [~Graftec@gateway/tor-sasl/graftec] has joined #bitcoin-wizards
18:59 -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards
19:11 < lechuga_> re: compact spv proofs, how will the verifier know the lucky PoWs actually exist in the chain? are they given merkle nodes to prove it?
19:12 < rusty> lechuga_: the proposal was to include a merkle of all previous block hashes in each block, so yes.
19:13 < manara> where can i learn more about the implementation of spv proofs?
19:13 < lechuga_> rusty: i thought only the root of the merkle was going to be added to blocks
19:14 < rusty> lechuga_: Yep, that was my "so yes": you need the merkle proof.
19:14 < lechuga_> i feel like i'd get so much more clarity with a simple drawing
19:16 < rusty> lechuga_: well, it's hard to draw all N-1 blocks being merkled into block N, for any reasonable N :)
19:16 < gmaxwell> lechuga_: what does 'added' in a block mean? in one sense a block is only 80 bytes, everything is just under a hash.  In the case of the commitments to prior blocks, anyone who would validate that block normally inherently knows the prior blocks, so you don't need to include anything but the hash. When one prepares a proof you go and expand out the hash walking... basically walking back in leaps
19:16 < gmaxwell> and bounds through past blocks by traversing down the hash tree.
19:17 < gmaxwell> rusty: right but it works if you just show a few in any case.
19:17 < lechuga_> gmaxwell: added == 32 more bytes to the block header for the merkle root
19:17 < rusty> lechuga_: naah, you can stash it in the coinbase.
19:18 < lechuga_> oh derp sure
19:18 < gmaxwell> lechuga_: in a new system you likely would move a number of things higher up. Not to the header perhaps.
19:19 -!- grau [~grau@37.143.74.116] has joined #bitcoin-wizards
19:21 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has joined #bitcoin-wizards
19:23 -!- grau [~grau@37.143.74.116] has quit [Ping timeout: 244 seconds]
19:25 -!- koeppelmann [~koeppelma@p4FDFA888.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
19:27 < lechuga_> so the proof is going to be something like a 'merklechain' msg which is similar in structure to a 'merkleblock' which will also be part of the proof for the block the tx exists in
19:27 < lechuga_> is that close to right?
19:28 < rusty> lechuga_: One step back.  What are you using compact spv proofs for?  Sidechains?
19:28 < lechuga_> trying to understand them in the context of sidechains, yeah
19:33 -!- nuke_ [~nuke@46-161-92.adsl.cyta.gr] has joined #bitcoin-wizards
19:33 < rusty> lechuga_: it's a good question, I haven't seen a precise proposal as to how it would be encoded in the scriptSig.  It's interesting, because the proof is going to be pretty big.
19:34 < lechuga_> i'm really terrible at reading an academic paper and seeing the code
19:35 < rusty> lechuga_: me too.  Though in my case clarity was only provided by clue drops from gmaxwell :)
19:36 < gmaxwell> well maaku's post is helpful if you haven't seen it.
19:36 -!- nuke1989 [~nuke@78-157-5.adsl.cyta.gr] has quit [Ping timeout: 256 seconds]
19:36 < gmaxwell> http://sourceforge.net/p/bitcoin/mailman/message/32111357/
19:36 < lechuga_> i actually got more mileage out of the high-value-hash-hwy thread
19:37 < gmaxwell> Probably not.
19:37 < lechuga_> need to re-read maaku's post a few more times though
19:37 < gmaxwell> HVHH is not the same thing. :) They're related.
19:37 < lechuga_> i more got from that the understanding of the lucky PoWs and why they prove the work
19:38 < lechuga_> not really any insight into the structure of the proof for sidechains
19:38 < gmaxwell> (I'd hang out and explain/chat but I'm exhausted and struggling to stay awake)
19:38 < lechuga_> lol np
19:38 < gmaxwell> lechuga_: fair enough.
19:38 < lechuga_> i need to bang my head against it more anyway
19:38 < lechuga_> and drive back home
19:39 < lechuga_> night!
19:42 < rusty> gmaxwell: oh, BTW, I ended up 4-line-hacking bitcoind to write out the missing/expected txs in each block, since BlueMatt's relay server was giving some weird results.  Now I'll just run it for a week somewhere to get results.  I'd really like to run one w/ relay client and one without at the same time though.
19:43 < BlueMatt> yea, I desperately need to spend a week on relay client digging out of the technical debt that thing's built up
19:44 < rusty> BlueMatt: it works, though.
19:44 < gmaxwell> BlueMatt: good, well I want to add a bunch of things to it. :P
19:45 -!- tdlfbx [~bsm117532@172-0-174-200.lightspeed.cicril.sbcglobal.net] has joined #bitcoin-wizards
19:46 -!- tdlfbx [~bsm117532@172-0-174-200.lightspeed.cicril.sbcglobal.net] has left #bitcoin-wizards []
19:47 -!- berndj [~berndj@azna.co.za] has quit [Excess Flood]
19:48 -!- berndj [~berndj@azna.co.za] has joined #bitcoin-wizards
19:54 < BlueMatt> gmaxwell: I didnt say clean it up /that/ much :p
19:54 < BlueMatt> rusty: indeed, and thats why I havent yet :)
19:56 -!- hashtagg_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards
19:57 -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 258 seconds]
20:02 -!- nubbins` [~leel@unaffiliated/nubbins] has joined #bitcoin-wizards
20:05 -!- jtimon_ [~quassel@127.pool85-53-130.dynamic.orange.es] has quit [Ping timeout: 258 seconds]
20:14 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 244 seconds]
20:16 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards
20:18 < maaku> lechuga_: the HVHH system doesn't work for this purpose
20:19 < maaku> as adversaries can produce fraudulent proofs with less than claimed expected work
20:20 < maaku> in the email I outline what the hash structure of the backlinks and commitments would look like, the serialization is "just details"
20:20 -!- adam3us [~Adium@host-92-18-104-28.as13285.net] has joined #bitcoin-wizards
20:21 < maaku> there's a cute structure for the back links which is a merklized heap filled by pushing nodes down the right-hand side
20:23 < maaku> it's deterministically constructed, and the verifyer only needs to store the right-hand path through the heap in working memory (a reorg requires the headers of the now stale chain)
20:24 -!- nubbins` [~leel@unaffiliated/nubbins] has quit [Read error: No route to host]
20:25 -!- nubbins` [~leel@unaffiliated/nubbins] has joined #bitcoin-wizards
20:30 < rusty> maaku: I think I need a diagram to follow that...
20:33 < rusty> maaku: intuitively though, an unbalanced tree makes sense, since most proofs are going to be for recent blocks.  Am I on the right track?
20:33 < maaku> it ends up being a not-more-than-1 unbalanced tree
20:33 -!- coiner [~linker@183.80.130.202] has quit [Ping timeout: 244 seconds]
20:34 < maaku> this isn't how i arrived at the structure, but it ends up being a binary patricia tree
20:37 < maaku> imagine representing the the path to a block as a big-endian bitness integer representation of the height
20:37 < maaku> meaning, store the height as an integer, and read off the bits starting with the MSB
20:37 < maaku> a 0- means take the left branch, a 1- means take the right branch
20:39 < rusty> maaku: OK, AFAICT this is exactly what you get if you take an array of values and naively merkle them together.
20:39 < maaku> ,,, rusty: scratch what I just said. i'm not efficiently multi tasking and describing something entirely different. gah
20:40  * maaku draws a paper and pencil diagram to make sure
20:40 < rusty> maaku: OK, well, it seems that the straightforward merkle-the-array-of-prev-blocks has the nice property that more recent blocks are generally on shorter paths.
20:41 < maaku> rusty: no, they're all at the bottom
20:41 < maaku> the one in the email has that property though
20:41 -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has quit [Ping timeout: 250 seconds]
20:42 < rusty> maaku: so, if we have 3 blocks, wouldn't you H(0|1), then H(H(0|1) | 2) ?
20:43 < maaku> rusty: the way bitcoin does it it'd be H(0|1) | H(2,2)
20:43 < maaku> if you fix that stupdity, you do get that property sometimes for the last (few) blocks
20:43 < maaku> but there's a better way
20:44 < rusty> maaku: yeah, sure, but the effect is the same.
20:44 -!- SubCreative is now known as Sub|music
20:44 < rusty> maaku: Oh, OK.  What's the better way?
20:44 < maaku> the goal is to fill out full trees, right?
20:44 < maaku> so take these rules
20:44 < maaku> if you have a full tree, extend the root so the old tree is the left branch of a new node
20:45 < maaku> then start filling out the right tree
20:45 < maaku> and you fill the right tree by "pushing down" nodes
20:45 < maaku> so the first entry into the right branch is the prior root
20:45 < maaku> at block height N, block N is the root
20:46 < maaku> and block N-1 is one of the branches (the right branch in this case)
20:46 < maaku> and continuing this exact case, block N-2 is the left branch, the root of that full tree
20:47 < maaku> anyway as you add blocks you keep pushing nodes of the tree down the right-hand path, preferentially taking left branches when empty
20:47 < maaku> until you reach the same depth as the rest of the tree
20:47 < maaku> it helps to draw this out on paper, starting with one node
20:48 < maaku> then you extend it to get node 2 in the root, with a final node 1 in the left branch
20:48 < maaku> then you push node 2 down to the right branch, where it is now final, and put node 3 as the root: 3 -> (1, 2)
20:49 < maaku> and continue ...
20:51 < maaku> this has the property that the most recent log(N) blocks are available in a direct chain from the root, with the most recent first, which is optimizing for the common case
20:51 < maaku> also, the max depth is one less then the construct-from-array approach because we're using internal nodes
20:51 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
20:52 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards
20:52 < maaku> and the already mentioned fact that you only actually need to store the right-side chain of nodes that are being "pushed down" -- the rest can be pruned from validator state
20:55 < rusty> maaku: if you want internal nodes (which I hadn't considered previously), isn't the optimal layout N on top, N-1 and N-2 below, N-3, N-4, N-5, N-6 below that, etc.. ie. breadth traversal? That would seem to give the minimal total size of proofs.
20:56 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Client Quit]
20:57 -!- d1ggy__ [~d1ggy@dslb-092-076-018-081.092.076.pools.vodafone-ip.de] has joined #bitcoin-wizards
20:58 < maaku> rusty: yes but that requires reconstructing the tree each block
20:58 < maaku> the question is how we can have a structure which achieves properties as close to that as possible, but with incremental construction and minimal storage requirements
20:59 < rusty> maaku: yeah, that does suck.  But if you end up limiting to (say) 1024 blocks back anyway because of concern about lucky cheaters, it's not so much of a problem.
21:00 < maaku> rusty: long skips are important
21:00 < maaku> we have some requirements for going all the way back to genesis
21:01 < rusty> maaku: for sidechains, you need only link to a previous output which itself links to ... the genesis.
21:01 -!- d1ggy_ [~d1ggy@dslb-092-076-018-081.092.076.pools.vodafone-ip.de] has quit [Ping timeout: 258 seconds]
21:01 < maaku> maybe. there's multiple designs with tradeoffs
21:01 < maaku> but this is larger than sidechains
21:02 -!- d1ggy__ [~d1ggy@dslb-092-076-018-081.092.076.pools.vodafone-ip.de] has quit [Ping timeout: 258 seconds]
21:02 < rusty> maaku: sure, but you have to come up with an alternate method for preventing lucky cheaters.  This one is simple, and everyone can understand breadth first without a diagram :)
21:03 < maaku> what i'm saying is there very well be cases where cheaters are not an issue
21:03 < maaku> e.g. you require short skips for recent history, but nevertheless have a requirement to link back to genesis
21:04 < maaku> as i said, compact spv is something used by sidechains, but not specific to sidechains
21:04 < maaku> you want links back to genesis for spv headers sync, for example
21:04 < maaku> cheaters isn't really a problem there
21:06 < rusty> maaku: OK, so another question.  Why do you think that you need incremental construction and minimal size?
21:06 < rusty> (Other than the fact that it's obvious a cool property to have)
21:07 < maaku> incremental construction is necessary to have any chance of this being accepted into core. otherwise it could take 1-2 sec or more to rebuild the header history
21:07 < rusty> maaku: but you can prebuild it trivially.
21:07 < maaku> keep in mind this would be done on asic controllers, typically low-powered arm boards or worse
21:08 < rusty> maaku: and slot in the new block hash when you get it.  I don't buy it.
21:08 < maaku> minimal size is nice because the validator state should not grow linearlly with history
21:08 < maaku> or else we're setting ourselves up for problems eventually
21:09 < maaku> comparing millinos of hashes vs a dozen or so? if you don't think that's a concern i don't know what to say
21:09 < rusty> maaku: not at 1.6MB per year, nope.
21:10 < rusty> maaku: millions?  We get 50,000 block headers a year.
21:10 -!- nubbins` [~leel@unaffiliated/nubbins] has quit [Quit: Quit]
21:11 < rusty> maaku: gavinandresen proposed ordering txs, too.  If we're doing that, it's hard to get upset about this.
21:12 -!- tacotime [~mashkeys@198.52.200.63] has joined #bitcoin-wizards
21:12 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards
21:14 -!- maraoz [~maraoz@181.29.97.171] has quit [Ping timeout: 244 seconds]
21:17 -!- fanquake [~anonymous@unaffiliated/fanquake] has quit [Quit: fanquake]
21:20 -!- grau [~grau@37.143.74.116] has joined #bitcoin-wizards
21:21 -!- fanquake [~anonymous@unaffiliated/fanquake] has joined #bitcoin-wizards
21:25 -!- grau [~grau@37.143.74.116] has quit [Ping timeout: 256 seconds]
21:26 -!- bitbumper [~bitbumper@161.47.143.24.cm.sunflower.com] has quit [Ping timeout: 272 seconds]
21:30 < rusty> maaku: I'm still trying to figure out your datastructure though.  Particularly trying to figure out when a block is in its final position.
21:32 -!- roidster [~chatzilla@96-41-48-194.dhcp.mtpk.ca.charter.com] has joined #bitcoin-wizards
21:35 -!- manara [835ebaa1@gateway/web/freenode/ip.131.94.186.161] has quit [Ping timeout: 246 seconds]
21:42 -!- fanquake [~anonymous@unaffiliated/fanquake] has quit [Quit: fanquake]
21:45 -!- ryanxcharles [~ryanxchar@2601:9:4680:dd0:607b:9839:e696:3fea] has joined #bitcoin-wizards
21:45 < bramc> Could people please start using different length nicks? Y'all look the same in xchat.
21:49 -!- adam3us [~Adium@host-92-18-104-28.as13285.net] has quit [Quit: Leaving.]
21:50 < Emcy> do you relly not have nick colours
21:50 -!- adam3us [~Adium@host-92-18-104-28.as13285.net] has joined #bitcoin-wizards
21:53 -!- coiner [~linker@113.161.87.238] has joined #bitcoin-wizards
22:00 -!- fanquake [~anonymous@unaffiliated/fanquake] has joined #bitcoin-wizards
22:04 < bramc> There are nick colors, but for some reason everybody is blue now. Y'all are running a hash collision attack on my chat.
22:05 < rusty> bramc: is your monitor cable loose? :)
22:06 < lechuga_> lol
22:13 < lechuga_> ok so the proof is just a merkle (maybe represented optimally as a patricia trie via a method i haven't digested yet) and the end leaves are the lucky PoWs
22:14 < fluffypony> that reminds me of a recent post on a Facebook group for 3DR Iris+ owners, some guy asked if everyone with "funny characters" in their name could change their names to English, otherwise he can't type out their names when he mentions them, and they all speak English anyway, so therefore.
22:15 < bramc> Okay, I'm off for now, probably will spend a few days off irc. Somebody let Adam know I gave him a mea culpa when he comes back on.
22:19 < lechuga_> need 2 read backlog with paper and pencil in hand when more awake
22:20 < adam3us> eh? this adam3us?
22:29 < adam3us> bramc: ah i see it (scroll back skim) paul sztorc's argument applied to depreciating hw electricity use.  yes that seems logical.
22:34 < adam3us> bramc: your second comment from scrollback "The best way to make cryptocurrencies be green is to lower mining rewards,"
22:36 -!- fanquake [~anonymous@unaffiliated/fanquake] has quit [Quit: fanquake]
22:36 < adam3us> bramc: i agree.  i made the what-if comment on this that hypothetically bitcoin (community economic supermajority) could decide to cancel the remaining reward schedule.  or defer the reward flattening the supply curve to spread the reward over a longer time.
22:38 < adam3us> bramc: or make the system reactive as a stabilising force which might reduce the problems miners are in right now (falling difficulty). my idea was maybe if difficulty rises above some threshold/time eg > 10% per 2week period, reward is deferred; and if it falls by > 10% per 2week period reward is brought forward.
22:40 < bramc> adam3us, Those are probably all political non-starters for the time being but likely to get interesting around 8-16 years from now. Assuming that interest in bitcoin hasn't already completely faded for other reasons by then of course
22:40 < adam3us> bramc: it would do something like gold price being self-stabalising because mining spins up and down in reaction to price.  here using rate of hashrate increase as a proxy for price mismatch we would similarly adjust reward.  one could adjust reward instead of difficulty (or some mix of the two)
22:41 < adam3us> bramc: yes my thought was what-if bitcoin is $100k/coin or $1mil per coin, the power usage might become problematic.  the money will be spent and it might lead to wars, global warming, blackouts or crazy stuff.  the meta-game theory then makes it plausible to voluntarily adjust to a reward adjusting rather than difficulty adjusting mechanism
22:42 < bramc> adam3us, I was thinking about the other contingency, where mining rewards have halved enough times that mining is barely happening any more
22:44 < adam3us> bramc: thats another open question is whether fees are enough to provide adequate security.  it could be argued the market would have all the tools it needs to take care of that.  pay higher fees.  we cant have ongoing subsidty for ever probably anyway or thats supply inflation at the steady state.
22:46 < adam3us> bramc: on the former i sort of wonder if at the limit ($1mil btcusd) the other implication is that pure difficulty adjustment as a sole feedback loop in fact will limit the price past some point.  maybe it even already is to some extent.
22:46 < bramc> I would argue that mining subsidies can easily be 2-3 orders of magnitude below transaction volume and it still won't be a security concern
22:49 < adam3us> bramc: all kinds of things are plausible in long run meta-game theory.  say fees just dont seem to give adequate security.  (market doesnt price security properly).  then lack of security damages utility, and price falls, such that people become more amenable to the idea of 1% supply inflation ongoing, or demurrage to miners (per year security tax basically) as a way to repair security.
22:49 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 265 seconds]
22:59 < bramc> The only real attacks are double spends, those aren't all that scary for the vast majority of transactions, and an attacker is only going to do a double-spend attack on transactions they themselves are involved in
22:59 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
23:06 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-wizards
23:06 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has quit [Changing host]
23:06 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-wizards
23:06 -!- grau [~grau@37.143.74.116] has joined #bitcoin-wizards
23:08 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 244 seconds]
23:09 -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has quit [Quit: Leaving]
23:10 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving]
23:18 -!- bit2017 [~linker@112.109.91.6] has joined #bitcoin-wizards
23:21 -!- coiner [~linker@113.161.87.238] has quit [Ping timeout: 258 seconds]
23:25 -!- bit2017 [~linker@112.109.91.6] has quit [Ping timeout: 256 seconds]
23:26 -!- roidster [~chatzilla@96-41-48-194.dhcp.mtpk.ca.charter.com] has quit [Ping timeout: 240 seconds]
23:30 -!- Burrito [~Burrito@unaffiliated/burrito] has quit [Quit: Leaving]
23:31 -!- bosma_ is now known as bosma
23:31 < maaku> lechuga_: no, you start with the block header. *IF* that block is a lucky block, you traverse the block-transaction merkle tree to the commitment tx (one of the last txns in the block, in a fixed pos), then traverse the block header merkle tree to the desired back link
23:32 < maaku> the back link itself might be a lucky PoW, but that's besides the point
23:35 -!- ebfull [~ebfull@c-76-120-40-34.hsd1.co.comcast.net] has joined #bitcoin-wizards
23:39 < lechuga_> i thought the back links were to gather sufficient # of lucky PoW to probablisitcally determine true current difficulty of the presented chain
23:39 < maaku> so the setup is you want to prove block B is a descendent of block A, and to keep it simple B is 'lucky' enough so as to represent more work than was strictly necessary to build from A to B
23:40 < maaku> so you descend through the transaction merkle tree to the one which contains the commitment, the commitment being the root hash of a block header merkle tree as specified above
23:40 -!- grau [~grau@37.143.74.116] has quit [Remote host closed the connection]
23:40 < maaku> you then descend to block A, which is at a known position
23:40 < maaku> lechuga_: no that is the high value hash highway
23:40 < maaku> nothing to do with this scheme
23:41 < lechuga_> oh i thought every block was going to have a committment to the block header merkle in the coinbase
23:41 < lechuga_> block header merkle root
23:41 < maaku> gotta run again :\
23:41 < maaku> not the coinbase, but yes
23:41 < lechuga_> k im too tired neway
23:41 < lechuga_> :)
23:42 < lechuga_> will read log
23:42 < lechuga_> thx maaku
23:43 < maaku> np
23:44 < maaku> also read sergio's mailing list post about merged mining header commitments
23:44 < maaku> that shows why the commitment is not in the coinbase
23:44 < maaku> the proof size can be made much smaller by making one of the last transactions at a fixed position
23:45 -!- MoALTz_ [~no@user-164-126-31-182.play-internet.pl] has quit [Quit: Leaving]
23:46 < lechuga_> k
23:50 < maaku> in the system i'm designing, the very last txn is used for data commitments (included merged mining), and then txns at positions N-1, N-2, etc. are used for consensus-checked commitments
23:51 < maaku> e.g. block header back-links, (U)TXO indices, etc.
23:55 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:3db5:f6f7:d6e2:13b7] has quit [Ping timeout: 258 seconds]