--- Day changed Wed Dec 10 2014
00:17 -!- paveljanik [~Pavel@unaffiliated/paveljanik] has quit [Ping timeout: 255 seconds]
00:29 -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards
00:33 -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Ping timeout: 245 seconds]
00:39 -!- Quanttek [~quassel@ip1f11225b.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards
00:41 -!- jtimon [~quassel@147.pool85-53-220.dynamic.orange.es] has joined #bitcoin-wizards
00:43 -!- Quanttek_ [~quassel@2a02:8108:d00:870:b9d5:480c:3fcd:e1d1] has joined #bitcoin-wizards
00:44 -!- Quanttek [~quassel@ip1f11225b.dynamic.kabel-deutschland.de] has quit [Ping timeout: 250 seconds]
00:44 -!- vmatekole [~vmatekole@p5DC4696B.dip0.t-ipconnect.de] has joined #bitcoin-wizards
00:45 -!- aburan28 [~ubuntu@static-108-45-93-73.washdc.fios.verizon.net] has quit [Ping timeout: 244 seconds]
00:48 -!- Quanttek_ [~quassel@2a02:8108:d00:870:b9d5:480c:3fcd:e1d1] has quit [Quit: No Ping reply in 180 seconds.]
00:52 -!- CoinMuncher [~jannes@178.132.211.90] has joined #bitcoin-wizards
00:53 -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards
00:57 -!- paveljanik [~Pavel@unaffiliated/paveljanik] has joined #bitcoin-wizards
00:58 < BlueMatt> anyone gonna be at 31c3?
01:02 -!- EasyAt [~EasyAt@unaffiliated/easyat] has quit [Ping timeout: 240 seconds]
01:04 -!- EasyAt [~EasyAt@unaffiliated/easyat] has joined #bitcoin-wizards
01:05 -!- andy-logbot [~bitcoin--@wpsoftware.net] has joined #bitcoin-wizards
01:05  * andy-logbot is logging
01:14 -!- Quanttek [~quassel@ip1f11225b.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards
01:14 -!- Quanttek [~quassel@ip1f11225b.dynamic.kabel-deutschland.de] has quit [Read error: Connection reset by peer]
01:17 -!- bramc [~bram@99.75.88.206] has joined #bitcoin-wizards
01:17 -!- TwoKoolFourSkewl [~TwoKoolFo@gateway/tor-sasl/twokoolfourskewl] has quit [Remote host closed the connection]
01:17 -!- TwoKoolFourSkewl [~TwoKoolFo@gateway/tor-sasl/twokoolfourskewl] has joined #bitcoin-wizards
01:23 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:e15c:2e9c:165d:832c] has quit [Ping timeout: 258 seconds]
01:25 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards
01:28 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #bitcoin-wizards []
01:38 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards
01:41 -!- Quanttek [~quassel@2a02:8108:d00:870:b9d5:480c:3fcd:e1d1] has joined #bitcoin-wizards
01:42 -!- EasyAt [~EasyAt@unaffiliated/easyat] has quit [Quit: leaving]
01:54 -!- Starduster_ [~guest@unaffiliated/starduster] has joined #bitcoin-wizards
01:56 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards
01:57 -!- Starduster [~guest@unaffiliated/starduster] has quit [Ping timeout: 240 seconds]
01:58 < bramc> Sure enough, the coinswap protocol is all about how to keep anonymity and does so in part by making the timelocks be in transactions which are usually cancelled.
02:15 -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has joined #bitcoin-wizards
02:19 -!- shesek [~shesek@87.68.245.176.adsl.012.net.il] has quit [Ping timeout: 264 seconds]
02:22 -!- lclc is now known as lclc_bnc
02:23 -!- Quanttek [~quassel@2a02:8108:d00:870:b9d5:480c:3fcd:e1d1] has quit [Ping timeout: 260 seconds]
02:24 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye]
02:27 -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has quit [Remote host closed the connection]
02:29 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards
02:31 -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards
02:35 -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Ping timeout: 255 seconds]
02:41 -!- bramc [~bram@99.75.88.206] has quit [Quit: This computer has gone to sleep]
02:47 -!- vmatekole [~vmatekole@p5DC4696B.dip0.t-ipconnect.de] has quit [Read error: Connection timed out]
02:48 -!- vmatekole [~vmatekole@p5DC4696B.dip0.t-ipconnect.de] has joined #bitcoin-wizards
02:49 -!- Quanttek [~quassel@ip1f1124bd.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards
02:50 -!- Quanttek [~quassel@ip1f1124bd.dynamic.kabel-deutschland.de] has quit [Read error: Connection reset by peer]
02:53 < petertodd> BlueMatt: was considering it
02:59 -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has joined #bitcoin-wizards
03:10 -!- zwischenzug [~zwischenz@204.Red-79-157-78.dynamicIP.rima-tde.net] has quit [Read error: Connection reset by peer]
03:10 -!- zwischenzug [~zwischenz@204.Red-79-157-78.dynamicIP.rima-tde.net] has joined #bitcoin-wizards
03:14 -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has quit [Remote host closed the connection]
03:20 -!- Quanttek [~quassel@ip1f1124bd.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards
03:20 -!- jtimon [~quassel@147.pool85-53-220.dynamic.orange.es] has quit [Ping timeout: 258 seconds]
03:21 -!- Quanttek [~quassel@ip1f1124bd.dynamic.kabel-deutschland.de] has quit [Read error: Connection reset by peer]
03:22 -!- atgreen [~user@CPE687f74122463-CM84948c2e0610.cpe.net.cable.rogers.com] has quit [Remote host closed the connection]
03:24 -!- paveljanik [~Pavel@unaffiliated/paveljanik] has quit [Quit: This computer has gone to sleep]
03:26 -!- Quanttek [~quassel@2a02:8108:d00:870:b9d5:480c:3fcd:e1d1] has joined #bitcoin-wizards
03:26 -!- Quanttek [~quassel@2a02:8108:d00:870:b9d5:480c:3fcd:e1d1] has quit [Read error: Connection reset by peer]
03:27 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection]
03:32 -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards
03:36 -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Ping timeout: 260 seconds]
03:43 -!- gues___ [~gues@cpe-66-68-54-206.austin.res.rr.com] has quit [Ping timeout: 260 seconds]
03:47 -!- nsh [~lol@2001:41d0:8:c2da::1337] has quit [Changing host]
03:47 -!- nsh [~lol@wikipedia/nsh] has joined #bitcoin-wizards
03:51 -!- Quanttek [~quassel@2a02:8108:d00:870:b9d5:480c:3fcd:e1d1] has joined #bitcoin-wizards
03:54 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Ping timeout: 256 seconds]
03:55 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
03:58 -!- lclc_bnc is now known as lclc
04:00 -!- gues [~gues@cpe-66-68-54-206.austin.res.rr.com] has joined #bitcoin-wizards
04:04 -!- shesek [~shesek@bzq-79-183-187-66.red.bezeqint.net] has joined #bitcoin-wizards
04:05 -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has quit [Quit: Textual IRC Client: www.textualapp.com]
04:09 -!- iang [~iang@skaro.afraid.org] has joined #bitcoin-wizards
04:10 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards
04:16 -!- bifforoni [~zorin@bzq-84-108-84-113.cablep.bezeqint.net] has joined #bitcoin-wizards
04:16 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
04:22 -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has joined #bitcoin-wizards
04:29 -!- bifforoni [~zorin@bzq-84-108-84-113.cablep.bezeqint.net] has quit [Quit: Leaving]
04:30 -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards
04:32 -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards
04:37 -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Ping timeout: 255 seconds]
04:44 -!- paveljanik [~Pavel@unaffiliated/paveljanik] has joined #bitcoin-wizards
04:59 -!- nsh [~lol@wikipedia/nsh] has quit [Excess Flood]
04:59 -!- nsh [~lol@2001:41d0:8:c2da::1337] has joined #bitcoin-wizards
05:02 -!- lclc is now known as lclc_bnc
05:03 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-wizards
05:05 -!- koeppelmann [~koeppelma@dyn-160-39-29-111.dyn.columbia.edu] has joined #bitcoin-wizards
05:11 -!- coiner [~linker@113.161.87.238] has quit [Ping timeout: 250 seconds]
05:15 -!- nsh [~lol@2001:41d0:8:c2da::1337] has quit [Excess Flood]
05:15 -!- nsh [~lol@2001:41d0:8:c2da::1337] has joined #bitcoin-wizards
05:15 -!- nsh [~lol@2001:41d0:8:c2da::1337] has quit [Changing host]
05:15 -!- nsh [~lol@wikipedia/nsh] has joined #bitcoin-wizards
05:16 -!- askmike [~askmike@83.162.194.88] has joined #bitcoin-wizards
05:23 -!- koeppelmann [~koeppelma@dyn-160-39-29-111.dyn.columbia.edu] has quit [Remote host closed the connection]
05:23 -!- koeppelmann [~koeppelma@dyn-160-39-29-111.dyn.columbia.edu] has joined #bitcoin-wizards
05:25 -!- vmatekole [~vmatekole@p5DC4696B.dip0.t-ipconnect.de] has quit [Read error: Connection timed out]
05:26 -!- vmatekole [~vmatekole@p5DC4696B.dip0.t-ipconnect.de] has joined #bitcoin-wizards
05:27 -!- koeppelm_ [~koeppelma@dyn-160-39-29-111.dyn.columbia.edu] has joined #bitcoin-wizards
05:27 -!- koeppelmann [~koeppelma@dyn-160-39-29-111.dyn.columbia.edu] has quit [Read error: Connection reset by peer]
05:27 -!- koeppelm_ [~koeppelma@dyn-160-39-29-111.dyn.columbia.edu] has quit [Remote host closed the connection]
05:27 -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 258 seconds]
05:27 -!- koeppelmann [~koeppelma@dyn-160-39-29-111.dyn.columbia.edu] has joined #bitcoin-wizards
05:32 -!- Greed [~Greed@unaffiliated/greed] has quit [Read error: Connection reset by peer]
05:32 -!- koeppelmann [~koeppelma@dyn-160-39-29-111.dyn.columbia.edu] has quit [Ping timeout: 260 seconds]
05:33 -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards
05:34 -!- koeppelmann [~koeppelma@dyn-160-39-29-111.dyn.columbia.edu] has joined #bitcoin-wizards
05:38 -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Ping timeout: 244 seconds]
05:42 -!- gues [~gues@cpe-66-68-54-206.austin.res.rr.com] has quit [Ping timeout: 245 seconds]
05:43 -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has joined #bitcoin-wizards
05:44 -!- gues_ [~gues@cpe-66-68-54-206.austin.res.rr.com] has joined #bitcoin-wizards
05:49 -!- hashtag [~hashtag@cpe-98-157-219-44.ma.res.rr.com] has joined #bitcoin-wizards
05:50 -!- paveljanik [~Pavel@unaffiliated/paveljanik] has quit [Ping timeout: 250 seconds]
05:59 -!- jtimon [~quassel@147.pool85-53-220.dynamic.orange.es] has joined #bitcoin-wizards
06:00 -!- hollandais [~irenacob@li629-190.members.linode.com] has quit [Max SendQ exceeded]
06:04 -!- hollandais [~irenacob@li629-190.members.linode.com] has joined #bitcoin-wizards
06:07 -!- lclc_bnc is now known as lclc
06:17 -!- jgarzik is now known as jgarzik_
06:18 -!- Quanttek [~quassel@2a02:8108:d00:870:b9d5:480c:3fcd:e1d1] has quit [Ping timeout: 260 seconds]
06:19 -!- Dr-G2 [~Dr-G@gateway/tor-sasl/dr-g] has joined #bitcoin-wizards
06:20 -!- koeppelm_ [~koeppelma@dyn-160-39-29-111.dyn.columbia.edu] has joined #bitcoin-wizards
06:20 -!- koeppelmann [~koeppelma@dyn-160-39-29-111.dyn.columbia.edu] has quit [Ping timeout: 244 seconds]
06:21 -!- Dr-G [~Dr-G@gateway/tor-sasl/dr-g] has quit [Ping timeout: 250 seconds]
06:34 -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards
06:34 -!- prodatalab [~prodatala@c-69-254-45-177.hsd1.fl.comcast.net] has quit [Quit: Konversation terminated!]
06:37 -!- prodatalab [~prodatala@c-69-254-45-177.hsd1.fl.comcast.net] has joined #bitcoin-wizards
06:39 -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Ping timeout: 258 seconds]
06:41 -!- treehug88 [~treehug88@66.6.34.252] has joined #bitcoin-wizards
06:45 -!- vmatekole [~vmatekole@p5DC4696B.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
06:45 -!- vmatekole [~vmatekole@p5DC4696B.dip0.t-ipconnect.de] has joined #bitcoin-wizards
06:46 -!- paveljanik [~Pavel@unaffiliated/paveljanik] has joined #bitcoin-wizards
06:50 -!- coiner [~linker@42.115.148.180] has joined #bitcoin-wizards
06:58 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards
07:03 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards
07:07 -!- Shiftos [~shiftos@gateway/tor-sasl/shiftos] has quit [Remote host closed the connection]
07:07 -!- Shiftos [~shiftos@gateway/tor-sasl/shiftos] has joined #bitcoin-wizards
07:14 -!- zooko [~user@c-76-120-75-214.hsd1.co.comcast.net] has joined #bitcoin-wizards
07:15 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye]
07:16 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards
07:16 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards
07:19 -!- user7779_ [user777907@gateway/vpn/mullvad/x-kffmkcoynbgjrzxg] has joined #bitcoin-wizards
07:19 -!- zooko [~user@c-76-120-75-214.hsd1.co.comcast.net] has quit [Ping timeout: 240 seconds]
07:21 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has quit [Ping timeout: 258 seconds]
07:22 -!- paveljanik [~Pavel@unaffiliated/paveljanik] has quit [Read error: Connection reset by peer]
07:25 -!- vdo [~vdo@unaffiliated/vdo] has joined #bitcoin-wizards
07:30 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards
07:32 -!- zooko [~user@c-76-120-75-214.hsd1.co.comcast.net] has joined #bitcoin-wizards
07:35 -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards
07:39 -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Ping timeout: 256 seconds]
07:46 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection]
07:50 -!- user7779_ [user777907@gateway/vpn/mullvad/x-kffmkcoynbgjrzxg] has quit [Remote host closed the connection]
07:55 -!- tdlfbx [~bsm117532@172-0-174-200.lightspeed.cicril.sbcglobal.net] has joined #bitcoin-wizards
07:57 -!- tdlfbx [~bsm117532@172-0-174-200.lightspeed.cicril.sbcglobal.net] has quit [Read error: Connection reset by peer]
07:57 -!- tdlfbx [~bsm117532@172-0-174-200.lightspeed.cicril.sbcglobal.net] has joined #bitcoin-wizards
08:04 -!- tdlfbx [~bsm117532@172-0-174-200.lightspeed.cicril.sbcglobal.net] has quit [Remote host closed the connection]
08:04 -!- koeppelm_ [~koeppelma@dyn-160-39-29-111.dyn.columbia.edu] has quit [Remote host closed the connection]
08:04 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
08:05 -!- koeppelmann [~koeppelma@dyn-160-39-29-111.dyn.columbia.edu] has joined #bitcoin-wizards
08:06 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards
08:09 -!- koeppelmann [~koeppelma@dyn-160-39-29-111.dyn.columbia.edu] has quit [Ping timeout: 264 seconds]
08:10 -!- user7779_ [user777907@gateway/vpn/mullvad/x-njtilxnphhoetezz] has joined #bitcoin-wizards
08:10 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has quit [Ping timeout: 272 seconds]
08:15 -!- koeppelmann [~koeppelma@dyn-160-39-29-111.dyn.columbia.edu] has joined #bitcoin-wizards
08:22 -!- austinhill1 [~Adium@12.176.89.5] has quit [Quit: Leaving.]
08:22 -!- austinhill [~Adium@69.38.214.164] has joined #bitcoin-wizards
08:28 -!- zooko [~user@c-76-120-75-214.hsd1.co.comcast.net] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
08:30 -!- zooko [~user@c-76-120-75-214.hsd1.co.comcast.net] has joined #bitcoin-wizards
08:35 -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has joined #bitcoin-wizards
08:40 -!- jb55 [~jb55@S0106f46d049a0b83.vc.shawcable.net] has quit [Ping timeout: 250 seconds]
08:44 -!- austinhill1 [~Adium@12.176.89.5] has joined #bitcoin-wizards
08:44 -!- btcdrak [uid52049@gateway/web/irccloud.com/x-awgvjiehhbljfeqz] has quit [Quit: Connection closed for inactivity]
08:46 -!- mappum [sid43795@gateway/web/irccloud.com/x-qioxqunmvuaneaeg] has quit [Ping timeout: 258 seconds]
08:46 -!- austinhill [~Adium@69.38.214.164] has quit [Ping timeout: 260 seconds]
08:47 -!- jbenet [sid17552@gateway/web/irccloud.com/x-ivavqwcqzpovlrwp] has quit [Ping timeout: 258 seconds]
08:48 -!- paveljanik [~Pavel@unaffiliated/paveljanik] has joined #bitcoin-wizards
08:50 -!- ryanxcharles [~ryanxchar@2601:9:4680:dd0:9025:83c2:6023:7f1] has quit [Ping timeout: 258 seconds]
08:51 -!- btcdrak [uid52049@gateway/web/irccloud.com/x-hvtoyxvhqhrevpfb] has joined #bitcoin-wizards
08:58 -!- CoinMuncher [~jannes@178.132.211.90] has quit [Quit: Leaving.]
09:00 -!- askmike [~askmike@83.162.194.88] has quit [Remote host closed the connection]
09:02 -!- zooko` [~user@c-76-120-75-214.hsd1.co.comcast.net] has joined #bitcoin-wizards
09:02 -!- zooko` [~user@c-76-120-75-214.hsd1.co.comcast.net] has quit [Remote host closed the connection]
09:02 -!- zooko [~user@c-76-120-75-214.hsd1.co.comcast.net] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
09:03 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye]
09:03 -!- op_null [~op_null@128.199.56.23] has joined #bitcoin-wizards
09:06 -!- ryanxcharles [~ryanxchar@162.245.22.162] has joined #bitcoin-wizards
09:08 < op_null> ;;later tell bramc "<bramc > ..the coinswap protocol is all about..anonymity" I'd hesitate to call it anything beyond a privacy measure. people expecting a system to provide true anonymity are going to be badly burned if it turns out to be flawed (as has happened in the past with services making similar promises).
09:08 < gribble> The operation succeeded.
09:10 -!- zooko [~user@c-76-120-75-214.hsd1.co.comcast.net] has joined #bitcoin-wizards
09:12 -!- eristisk [~eristisk@gateway/tor-sasl/eristisk] has joined #bitcoin-wizards
09:17 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards
09:17 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Read error: Connection reset by peer]
09:18 -!- mortale [~mortale@gateway/tor-sasl/mortale] has joined #bitcoin-wizards
09:18 -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Remote host closed the connection]
09:20 -!- atgreen [~user@206-71-239-16.c3-0.nyw-ubr1.nyr-nyw.ny.cable.rcn.com] has joined #bitcoin-wizards
09:30 -!- shesek [~shesek@bzq-79-183-187-66.red.bezeqint.net] has quit [Ping timeout: 244 seconds]
09:33 -!- zooko [~user@c-76-120-75-214.hsd1.co.comcast.net] has quit [Ping timeout: 258 seconds]
09:36 -!- vdo [~vdo@unaffiliated/vdo] has quit [Quit: Lost terminal]
09:40 -!- lclc is now known as lclc_bnc
09:41 -!- jbenet [sid17552@gateway/web/irccloud.com/x-xtmursypopjedpok] has joined #bitcoin-wizards
09:44 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards
09:48 -!- austinhill1 [~Adium@12.176.89.5] has quit [Quit: Leaving.]
09:51 -!- br4n [~quassel@vpn-ord.corvisa.com] has joined #bitcoin-wizards
09:51 -!- br4n [~quassel@vpn-ord.corvisa.com] has quit [Read error: Connection reset by peer]
09:51 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards
09:57 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection]
09:59 -!- jb55 [~jb55@208.98.200.98] has joined #bitcoin-wizards
10:10 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
10:10 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Remote host closed the connection]
10:10 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
10:12 -!- jb55 [~jb55@208.98.200.98] has quit [Remote host closed the connection]
10:13 -!- jb55 [~jb55@208.98.200.98] has joined #bitcoin-wizards
10:15 -!- Profreid [~Profreitt@46.166.186.238] has joined #bitcoin-wizards
10:17 -!- jb55 [~jb55@208.98.200.98] has quit [Ping timeout: 264 seconds]
10:18 -!- cbeams [~cbeams@212-17-107-66.static.inode.at] has joined #bitcoin-wizards
10:18 -!- cbeams [~cbeams@212-17-107-66.static.inode.at] has quit [Changing host]
10:18 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards
10:19 -!- jb55 [~jb55@208.98.200.98] has joined #bitcoin-wizards
10:19 -!- mappum [sid43795@gateway/web/irccloud.com/x-xvpohabtmppamubg] has joined #bitcoin-wizards
10:29 -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards
10:29 -!- bitbumper [~bitbumper@197.115.124.24.cm.sunflower.com] has joined #bitcoin-wizards
10:32 -!- jtimon [~quassel@147.pool85-53-220.dynamic.orange.es] has quit [Ping timeout: 240 seconds]
10:34 -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Ping timeout: 250 seconds]
10:34 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection]
10:38 -!- cbeams [~cbeams@212-17-107-66.static.inode.at] has joined #bitcoin-wizards
10:38 -!- cbeams [~cbeams@212-17-107-66.static.inode.at] has quit [Changing host]
10:38 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards
10:39 -!- jgarzik_ is now known as jgarzik
10:39 -!- grau [~grau@37.143.74.116] has joined #bitcoin-wizards
10:41 -!- Quanttek [~quassel@ip1f1124bd.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards
10:41 -!- Quanttek [~quassel@ip1f1124bd.dynamic.kabel-deutschland.de] has quit [Read error: Connection reset by peer]
10:46 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Ping timeout: 250 seconds]
10:46 -!- Quanttek [~quassel@2a02:8108:d00:870:a904:190c:4ff6:aa77] has joined #bitcoin-wizards
10:48 -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has joined #bitcoin-wizards
10:51 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards
10:52 -!- Quanttek [~quassel@2a02:8108:d00:870:a904:190c:4ff6:aa77] has quit [Read error: Connection reset by peer]
10:55 -!- Quanttek [~quassel@ip1f112250.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards
10:55 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye]
10:56 -!- Quanttek [~quassel@ip1f112250.dynamic.kabel-deutschland.de] has quit [Read error: Connection reset by peer]
11:01 -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards
11:02 < bramc> op_null, Hah, I'm not claiming that it produces absolute anonymity, just that the design of the protocol is very much about trying to get as much anonymity as it can under the circumstances
11:04 < bramc> Working on anonymity in general sucks that way
11:05 -!- Burrito [~Burrito@unaffiliated/burrito] has joined #bitcoin-wizards
11:05 < phantomcircuit> bramc, i suspect that with coinjoin and fixed size outputs you can achieve anonymity equal to the anonymity of the connection to the coordinator
11:05 < op_null> bramc: yes, I have the same sort of feeling for working on privacy software that I do for wallets in general. no way in hell can I be trusted to write something like that without significant review.. but other people seem to be doing it just fine.
11:06 -!- Dizzle [~diesel@207.11.113.29] has joined #bitcoin-wizards
11:06 < bramc> I'm specifically commenting on it because of the question of whether timelocks should be in transactions or utxos. Writing the same protocols with them being in utxos winds up feeling hackier and with more data included in the blockchain
11:07 < bramc> op_null, The creation of tor was very much a 'hold your nose and accept the threat model' admission to practicality. Everybody wanted to work on mixes because those can sort of actually protect privacy
11:08 < bramc> But obviously tor does a lot more  for actually protecting anonymity in the real world than email mixes do.
11:11 -!- Dizzle__ [~diesel@70.114.207.41] has joined #bitcoin-wizards
11:11 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection]
11:11 < op_null> money is high impact too.
11:11 -!- Dizzle [~diesel@207.11.113.29] has quit [Disconnected by services]
11:11 < phantomcircuit> bramc, well yes but only because email security is such shit that nobody sane would send all of their mail through a mix network
11:11 -!- Dizzle__ is now known as Dizzle
11:11 < op_null> if people use a "mixer" for many years only to find that it's broken, the impact could be huge.
11:13 < bramc> phantomcircuit, mix nets for high latency things like email can inherently be made much better, because you can quantize when all the mail is sent so an attacker can't correlate by timing, but the problem is people don't want to do everything via email, they want to do everything via the web, so there's many more orders of magnitude cover traffic for real time mix nets than delayed mix nets
11:15 < bramc> op_null, The same concerns apply for all kinds of mixnets, including tor. Working on anonymity sucks like that.
11:15 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:eda8:1d94:c142:f93a] has joined #bitcoin-wizards
11:16 < phantomcircuit> bramc, yes but it should be possible to implement a mixnet on top of tor
11:16 -!- Baz__ [~Baz@cpe-67-244-112-191.nyc.res.rr.com] has joined #bitcoin-wizards
11:16 -!- bifforoni [~zorin@bzq-84-108-84-113.cablep.bezeqint.net] has joined #bitcoin-wizards
11:17 < bramc> phantomcircuit, Yes you could build an email mixnet on top of tor. That hasn't been done because there's very little demand for it and everybody's busy trying to improve tor itself.
11:18 -!- grau [~grau@37.143.74.116] has quit [Remote host closed the connection]
11:19 < kanzure> this one seems to be a thing http://diyhpl.us/~bryan/papers2/security/pynchon/pynchon-spec.txt
11:21 < kanzure> actually i don't understand why this was based on email
11:22 -!- Profreid [~Profreitt@46.166.186.238] has quit [Quit: Profreid]
11:22 < kanzure> aren't there lots of text-based mixing scenarios that could benefit from not being related to smtp?
11:22 < jgarzik> starttls lol
11:23 -!- bitbumper [~bitbumper@197.115.124.24.cm.sunflower.com] has quit [Ping timeout: 244 seconds]
11:23 -!- waxwing [~waxwing@193.138.219.233] has quit [Ping timeout: 260 seconds]
11:26 < bramc> kanzure, Same reason as tor supports real time TCP: Cover traffic. Usability matters.
11:27 -!- Quanttek [~quassel@ip1f112250.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards
11:27 < bramc> kanzure, You might notice that my name is at the top of that thing. Unfortunately I think work on it has stalled out.
11:27 -!- Quanttek [~quassel@ip1f112250.dynamic.kabel-deutschland.de] has quit [Read error: Connection reset by peer]
11:28 < phantomcircuit> bramc, wouldn't only supporting smtp limit the amount of cover traffic?
11:28 < bramc> phantomcircuit, No, because nobody's asked for any other cover traffic to be supported. You'd have to get people to start using something completely new
11:29 < bramc> Well, these days there are messenger apps, maybe one of them could do it.
11:29 < bramc> But those are also unfortunately very centralized
11:30 < bramc> And you don't really get the anonymity benefits until you start adding hours to the delay times.
11:30 -!- grau [~grau@37.143.74.116] has joined #bitcoin-wizards
11:31 < op_null> I wonder how long it'll take for somebody to set up a darkwallet server, sniff all of the coinjoins and blackmail people for it.
11:31 < kanzure> bramc: were you considering any other sort of protocol other than smtp?
11:31 < kanzure> i don't have any suggestions off the top of my head, so i will pester you for them
11:32 < bramc> I haven't yet *fully* grokked coinswap. Once I do I'll go over coinjoin and be able to speak intelligently about their relative anonymity properties
11:32 < phantomcircuit> bramc, for high volume small messages delays of even a few seconds might be enough
11:32 < bramc> kanzure, This was a number of years ago, when email still ruled the world, so no there weren't any such thoughts but maybe something new could be made now.
11:32 < phantomcircuit> at the very least it would be better
11:32 < kanzure> i don't think xmpp would tolerate multi-month delays
11:33 -!- Quanttek [~quassel@2a02:8108:d00:870:a904:190c:4ff6:aa77] has joined #bitcoin-wizards
11:33 < bramc> phantomcircuit, Yes it would but it's hard to make pynchon gate work for that. Whether it could is an interesting question.
11:33 < isis> (actually, as a tor developer, i would like to point out that it's currently quite difficult to build an email mixnet on top of tor… we don't support MX or SRV records yet, though there is a proposal to accept all DNS types: https://gitweb.torproject.org/torspec.git/tree/proposals/219-expanded-dns.txt )
11:33 < kanzure> but that's "raw" email
11:34 < isis> sure, you can do "not real email" and pass the records around by hand, but the rest of the email world probably won't ever talk to whatever protocol you make up
11:34 < bramc> Really though, the thing holding up even having a good prototype of pynchon gate is resources. I'm busy with other things, Nick is busy with tor, and Len's productivity has been severely limited.
11:35 -!- waxwing [waxwing@gateway/vpn/mullvad/x-rhmcltdyacgjrygk] has joined #bitcoin-wizards
11:36 < isis> having a pyncheon gate would be excellent however :)
11:36 < kanzure> isis: i don't know whether "the rest of the email world" is that important in that scheme, to be honest
11:36 < bramc> isis, no doubt. If anyone goes ahead and builds it we would all be very appreciative.
11:41 < isis> kanzure: i don't know either… though systems which have tried to redesign a privacy-preserving email-like messaging system which required custom servers and clients haven't seen much adoption, so one might prefer a protocol compatible with non-hacked-up Postfix servers in the rest of the email world in order to drive adoption.
11:42 < op_null> compatibility is how you get POODLEs though :)
11:42 < isis> but yes, it also could be junked. there's nothing worth saving from the design of email anyway. :)
11:42 < kanzure> i don't even know if email is good for very long delay... most email clients bury old stuff from the user
11:42 -!- Quanttek [~quassel@2a02:8108:d00:870:a904:190c:4ff6:aa77] has quit [Read error: Connection reset by peer]
11:42 -!- Quanttek [~quassel@2a02:8108:d00:870:a904:190c:4ff6:aa77] has joined #bitcoin-wizards
11:42 < kanzure> and new replies bump the old email thread, but that's not helpful (the nature of long delays probably requires you to be aware or shown which things you are waiting on, in a more protocol-specific way)
11:43 < bramc> op_null, What do you mean by POODLE?
11:43 < kanzure> well anyway, that is just ui, could still hack email
11:44 < op_null> bramc: sort of a joke, it's the TLS downgrade attack that was quite recent.
11:44 < op_null> bramc: https://www.openssl.org/~bodo/ssl-poodle.pdf
11:48 -!- vmatekole [~vmatekole@p5DC4696B.dip0.t-ipconnect.de] has quit [Read error: Connection timed out]
11:49 < bramc> kanzure, Back in the day email clients sorted by received time. An unfortunate number of them now sort by reported send time, which is fairly busted behavior
11:49 -!- vmatekole [~vmatekole@p5DC4696B.dip0.t-ipconnect.de] has joined #bitcoin-wizards
11:49 < op_null> bramc: I like it. it's a good bug to abuse.
11:50 < op_null> "you never sent that to me!" "sure I did, look it's unread all the way down at the bottom ;)"
11:50 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Remote host closed the connection]
11:51 -!- grau [~grau@37.143.74.116] has quit [Remote host closed the connection]
11:53 < bramc> Yeah, busted behavior, spammers use it too
11:54 -!- user7779_ [user777907@gateway/vpn/mullvad/x-njtilxnphhoetezz] has quit [Remote host closed the connection]
11:56 < isis> bramc: if at some point you'll be going over coinjoin and coinswap and their relative anonymity properties, i'd be quite curious to hear your thoughts
11:56 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards
11:59 < gmaxwell> he's not going over their privacy properties. He was pondering how timelocks need to work. And observed that coinswap more or less depends on timelocks being specified in the spending transactions (though, this could also be accomplished with delegation).
11:59 -!- user7779_ [user777907@gateway/vpn/mullvad/x-seudhsypfbamkszt] has joined #bitcoin-wizards
12:01 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has quit [Ping timeout: 255 seconds]
12:01 < zooko> Wow, this is interesting: http://www.theverge.com/2014/12/10/7361603/bittorrenet-wants-to-change-the-way-the-web-is-built
12:02 < op_null> had better not contain the words "blockchain technology"
12:02 < fluffypony> hah
12:02 < fluffypony> blockchain 3.0
12:02 < zooko> lol
12:03 -!- orik [~orik@remote.snococpa.com] has joined #bitcoin-wizards
12:04 < bramc> gmaxwell, There was some earlier discussion where someone said that coinjoin is almost/about as private. I need to finish going over them to respond intelligently to that one.
12:05 < fluffypony> "BitTorrent CEO Eric Klinker"
12:05 < fluffypony> no wonder the public expects Bitcoin to have a CEO
12:06 < op_null> just make it Andreas M. Antonopoulos and get the stupidity over with.
12:07  * fluffypony giggles
12:07 < lechuga_> zooko: whoa that is cool
12:07 -!- instagibbs [32f65962@gateway/web/freenode/ip.50.246.89.98] has joined #bitcoin-wizards
12:08 < instagibbs> *adds blockchain to BitTorrent, calls it Bittorrent 2.0*
12:10 < fluffypony> oh speaking of academia with nearly no details - https://www.cryptocoinsnews.com/the-mathematically-secure-way-to-accept-zero-confirmation-transactions/
12:10 -!- mkarrer [~mkarrer@197.Red-81-44-7.dynamicIP.rima-tde.net] has quit [Read error: Connection reset by peer]
12:11 < kanzure> blockchain 4.0 advocates have it all backwards, it's supposed to be exponentially increasing towards 0
12:11 < op_null> fluffypony: right, more timing bullshit. if everybody who claims to connect to ever node actually did, we'd be in a lot of trouble.
12:11 -!- mkarrer [~mkarrer@197.Red-81-44-7.dynamicIP.rima-tde.net] has joined #bitcoin-wizards
12:11 < fluffypony> old article, but I haven't stumbled across any detail on how "transaction confidence" is determined beyond "a lot of nodes we're watching have received this tx"
12:12 < op_null> "BitPay has done tens of thousands of Bitcoin transactions in this manner and has not had one instance of a double spend." I find that hard to believe.
12:12 < kanzure> consider that the cost of a reorg is pretty high for that 0.0001 BTC transaction you made
12:12 < fluffypony> http://dev.blockcypher.com/reference.html#zero_confirmations
12:12 < Luke-Jr> kanzure: bad logic
12:12 -!- jtimon [~quassel@147.pool85-53-220.dynamic.orange.es] has joined #bitcoin-wizards
12:12 < kanzure> also what size do you expect most bitpay transactions to be
12:12 -!- bitbumper [~bitbumper@129.237.222.129] has joined #bitcoin-wizards
12:13 < op_null> kanzure: I can finney attack you without mining a single block.
12:13 < Luke-Jr> kanzure: if you double spend, you can double spend a lot more than one transaction at once
12:13 < kanzure> maybe their definition of double spend is not double spend zero confirmations
12:13 < op_null> it is.
12:13 < Luke-Jr> accepting UNconfirmed transactions only makes sense if someone is physically in front of you (AND it's low value)
12:13 < kanzure> "double_spend_tx: the hash of the other transaction involved in the double spend attempt" only one?
12:14 < kanzure> op_null: so then you hold that bitpay is intentionally lying ?
12:14 < instagibbs> Luke-Jr: or you're just ok getting double-spent against. Something like a donation jar for music
12:14 < op_null> kanzure: no, the article is.
12:14 < Luke-Jr> "zero confirmation" is snake oil. it's not "zero", it's "not"
12:14 < kanzure> op_null: oh, that's less interesting.
12:14 < Luke-Jr> instagibbs: sure
12:14 < Luke-Jr> instagibbs: you might also have insurance
12:15 < op_null> kanzure: ha, yeah I wrote the tools to hammer the bitcoin network with double spends just to see what would happen. resigned one transaction n times and force pushed the inventory to every connected node. never used it, but it was a fun concept.
12:15 < instagibbs> Bitpay is probably ok given the current volume of txns. But as transactions scale, yeah it's really dangerous sans insurance.
12:16 < op_null> kanzure: I wrote it with the original concept of trying to find dual and tri stack nodes, but it turns out people's mempools are unique enough to act as a fingerprint without poisoning.
12:17 < kanzure> if a transaction is never reported to a service's users, what's the point of fingerprinting their mempool? you wont see results, i think
12:18 < op_null> well, like I said the concept was trying to find nodes with multiple interfaces.
12:18 < kanzure> what are you using these fingerprints for?
12:18 < kanzure> hm
12:18 -!- woah [~woah@75-101-111-82.dedicated.static.sonic.net] has joined #bitcoin-wizards
12:20 < op_null> no real use beyond finding out if I could or not.
12:21 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
12:23 -!- askmike_ [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
12:25 -!- askmike__ [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
12:25 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 240 seconds]
12:27 -!- askmike_ [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 240 seconds]
12:29 -!- askmike__ [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 240 seconds]
12:30 -!- moa [~moa@opentransactions/dev/moa] has joined #bitcoin-wizards
12:38 -!- mode/#bitcoin-wizards [+o gwillen] by ChanServ
12:38 <@gwillen>  +e $a:Profreid
12:38 <@gwillen> heh, oops :-)
12:38 -!- mode/#bitcoin-wizards [-o gwillen] by gwillen
12:39 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:eda8:1d94:c142:f93a] has quit [Ping timeout: 258 seconds]
12:39 -!- Profreid [~Profreitt@109.201.154.150] has joined #bitcoin-wizards
12:41 -!- instagibbs [32f65962@gateway/web/freenode/ip.50.246.89.98] has quit [Quit: Page closed]
12:42 -!- grandmaster [dansmith3@knows.the.cops.are.investigat.in] has quit [Quit: quit]
12:42 -!- grandmaster [dansmith3@knows.the.cops.are.investigat.in] has joined #bitcoin-wizards
12:45 -!- grau [~grau@37.143.74.116] has joined #bitcoin-wizards
12:46 -!- vmatekole [~vmatekole@p5DC4696B.dip0.t-ipconnect.de] has quit [Ping timeout: 244 seconds]
12:48 -!- bitbumper [~bitbumper@129.237.222.129] has quit [Ping timeout: 244 seconds]
12:50 -!- woah [~woah@75-101-111-82.dedicated.static.sonic.net] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
13:01 < bramc> petertodd, What specific opcode functionality would you like added to support fidelity bonding?
13:04 -!- user7779_ [user777907@gateway/vpn/mullvad/x-seudhsypfbamkszt] has quit [Remote host closed the connection]
13:04 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards
13:08 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has quit [Ping timeout: 240 seconds]
13:15 -!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has joined #bitcoin-wizards
13:15 -!- cbeams [~cbeams@chello084114181075.1.15.vie.surfer.at] has quit [Changing host]
13:15 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards
13:17 -!- cbeams [~cbeams@unaffiliated/cbeams] has quit [Remote host closed the connection]
13:26 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
13:27 -!- nullbyte [WW@gateway/vpn/mullvad/x-ynmdrayylkyaommc] has quit [Ping timeout: 260 seconds]
13:29 -!- nullbyte [~WW@unaffiliated/loteriety] has joined #bitcoin-wizards
13:31 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 256 seconds]
13:33 -!- nubbins` [~leel@unaffiliated/nubbins] has quit [Quit: Quit]
13:35 -!- nubbins` [~leel@unaffiliated/nubbins] has joined #bitcoin-wizards
13:45 -!- grau [~grau@37.143.74.116] has quit [Remote host closed the connection]
13:46 -!- Profreid [~Profreitt@109.201.154.150] has quit [Quit: Profreid]
13:48 < dgenr8> double-spend attack designed for a network where miners all mine first spend seen: https://github.com/bitcoin/bitcoin/pull/4570#issuecomment-53138831
13:50 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
14:01 -!- wyager [~wyager@nat-128-62-64-112.public.utexas.edu] has joined #bitcoin-wizards
14:02 < bramc> dgenr8, Looks like that just relies on the receiver accepting the transaction way too quickly?
14:05 < gmaxwell> dgenr8: welcome to 2009? That kind of transaction pattern is what I was trying to open your eyes to when you were making proposals that miners orphan blocks which contain "double spends".
14:06 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards
14:07 -!- bitbumper [~bitbumper@197.115.124.24.cm.sunflower.com] has joined #bitcoin-wizards
14:08 -!- PRab_ [~chatzilla@c-98-209-175-70.hsd1.mi.comcast.net] has joined #bitcoin-wizards
14:08 -!- hashtag [~hashtag@cpe-98-157-219-44.ma.res.rr.com] has quit [Ping timeout: 255 seconds]
14:09 -!- PRab [~chatzilla@c-98-209-175-70.hsd1.mi.comcast.net] has quit [Ping timeout: 258 seconds]
14:09 -!- PRab_ is now known as PRab
14:10 -!- woah [~woah@75-101-111-82.dedicated.static.sonic.net] has joined #bitcoin-wizards
14:10 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 258 seconds]
14:11 -!- ebfull [~ebfull@c-76-120-40-34.hsd1.co.comcast.net] has quit [Quit: cya]
14:11 -!- ebfull [~ebfull@c-76-120-40-34.hsd1.co.comcast.net] has joined #bitcoin-wizards
14:11 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has joined #bitcoin-wizards
14:11 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-wizards
14:12 < midnightmagic> case- and graph-based reasoning to justify additional tx handling logic is extremely hard to be complete about. presuming I understand the rationale behind the change, (since the code doesn't appear to special-case the way the reasoning does) then the payment graph of cases you are considering is incomplete and similar in nature and scope to (unsolveable IMO) branching and merging problems.
14:12 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has quit [Remote host closed the connection]
14:13 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has joined #bitcoin-wizards
14:14 -!- nubbins` [~leel@unaffiliated/nubbins] has quit [Quit: Quit]
14:14 < kanzure> there's definitely something similar to a merging thing going on here, yeah
14:14 < midnightmagic> but I like the idea of rate-limiting respends. :-)
14:15 < kanzure> in many cases a transaction that gets an extra input or an extra output, all else being equal (like other previously existing outputs), tends to be okay to consider to be the same transaction, i think
14:15 < dgenr8> gmaxwell: you're no fun anymore
14:15 < midnightmagic> lol
14:15 < kanzure> although maybe i should constrain myself to only talking about a user wallet
14:16 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards
14:16 < kanzure> it's some sort of bookkeeping-related merging
14:17 < kanzure> at minimum you would probably have to always show the user previous pre-merged stuff so they can follow along with what has happened
14:17 < kanzure> (or not happened)
14:17 -!- shesek [~shesek@87.68.245.176.adsl.012.net.il] has joined #bitcoin-wizards
14:17 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye]
14:19 -!- bifforoni [~zorin@bzq-84-108-84-113.cablep.bezeqint.net] has quit [Quit: Leaving]
14:20 < bramc> gmaxwell, Aren't blocks which contain double spends considered ill-formed?
14:20 < tromp_> if the other spend is in ancestor block, then yes of course
14:20 < phantomcircuit> bramc, he's talking about double spend prevention outside of the proof of work consensus system
14:21 < midnightmagic> a block which contains a double-spend or completes a double-spend will simply be rejected outright by the network.
14:21 < phantomcircuit> ie shit that doesn't really work
14:22 < bramc> oh, yeah, double spend prevention is the whole point of bitcoin, if there much you could do outside of that you wouldn't need all that resource waste on mining.
14:22 < op_null> yep
14:23 < op_null> the times people are talking about a double spend, it's usually a finney attack (broadcast a transaction, mine a block with a different transaction spending the same output)
14:23 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
14:24 < op_null> or a full blown reorg where somebody mines back from the head and undoes a transaction, spending it elsewhere. we've seen real world finney attacks, but I don't think any forced reorgs to double spend.
14:25 < bramc> This is why you wait for a few blocks to have passed before counting a transaction as really having happened
14:25 < dgenr8> op_null: you weren't referring to 0-conf in relation to bitpay above?
14:26 < op_null> dgenr8: kinda just in general.
14:27 -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
14:28 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 256 seconds]
14:40 < gmaxwell> bramc: thus the scare-quotes.
14:41 < bramc> reorg attacks become a problem when transaction fees are far in excess of mining rewards
14:41 < gmaxwell> bramc: in that case it means that block contained transactions you thought it ought to have not contained.
14:46 -!- Greed [~Greed@unaffiliated/greed] has joined #bitcoin-wizards
14:47 -!- AnoAnon [~AnoAnon@197.37.107.51] has joined #bitcoin-wizards
14:47 -!- AnoAnon [~AnoAnon@197.37.107.51] has quit [Max SendQ exceeded]
14:52 -!- belcher [~belcher-s@unaffiliated/belcher] has joined #bitcoin-wizards
14:53 -!- xabbix [~orw@unaffiliated/xabbix] has joined #bitcoin-wizards
14:55 -!- TwoKoolFourSkewl [~TwoKoolFo@gateway/tor-sasl/twokoolfourskewl] has quit [Ping timeout: 250 seconds]
14:56 -!- Greed` [~Greed@unaffiliated/greed] has joined #bitcoin-wizards
14:56 -!- koeppelmann [~koeppelma@dyn-160-39-29-111.dyn.columbia.edu] has quit [Remote host closed the connection]
14:57 -!- Greed [~Greed@unaffiliated/greed] has quit [Disconnected by services]
14:57 -!- Greed` is now known as Greed
14:57 -!- koeppelmann [~koeppelma@dyn-160-39-29-111.dyn.columbia.edu] has joined #bitcoin-wizards
14:57 -!- TwoKoolFourSkewl [~TwoKoolFo@gateway/tor-sasl/twokoolfourskewl] has joined #bitcoin-wizards
15:01 -!- mortale [~mortale@gateway/tor-sasl/mortale] has quit [Remote host closed the connection]
15:02 -!- koeppelmann [~koeppelma@dyn-160-39-29-111.dyn.columbia.edu] has quit [Ping timeout: 272 seconds]
15:03 -!- mortale [~mortale@gateway/tor-sasl/mortale] has joined #bitcoin-wizards
15:04 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards
15:05 -!- wyager [~wyager@nat-128-62-64-112.public.utexas.edu] has quit [Quit: wyager]
15:09 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has quit [Ping timeout: 244 seconds]
15:11 -!- Quanttek [~quassel@2a02:8108:d00:870:a904:190c:4ff6:aa77] has quit [Ping timeout: 265 seconds]
15:11 -!- woah [~woah@75-101-111-82.dedicated.static.sonic.net] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
15:14 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards
15:14 -!- nullbyte [~WW@unaffiliated/loteriety] has quit [Ping timeout: 252 seconds]
15:15 -!- nullbyte [~WW@unaffiliated/loteriety] has joined #bitcoin-wizards
15:16 -!- Shiftos [~shiftos@gateway/tor-sasl/shiftos] has quit [Ping timeout: 250 seconds]
15:18 -!- user7779_ [user777907@gateway/vpn/mullvad/x-csjeubojlpylrafq] has joined #bitcoin-wizards
15:19 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has quit [Ping timeout: 264 seconds]
15:25 -!- treehug88 [~treehug88@66.6.34.252] has quit []
15:31 -!- luny [~luny@unaffiliated/luny] has quit [Read error: Connection reset by peer]
15:32 -!- ebfull [~ebfull@c-76-120-40-34.hsd1.co.comcast.net] has quit [Quit: cya]
15:32 -!- ebfull [~ebfull@c-76-120-40-34.hsd1.co.comcast.net] has joined #bitcoin-wizards
15:34 -!- luny [~luny@unaffiliated/luny] has joined #bitcoin-wizards
15:46 -!- starsoccer [~starsocce@unaffiliated/starsoccer] has quit [Ping timeout: 256 seconds]
15:47 -!- starsoccer [~starsocce@104.219.184.48] has joined #bitcoin-wizards
15:47 -!- starsoccer is now known as Guest15960
15:51 -!- gsdgdfs is now known as Transisto
15:52 -!- Guest15960 [~starsocce@104.219.184.48] has quit [Ping timeout: 256 seconds]
15:59 -!- paveljanik [~Pavel@unaffiliated/paveljanik] has quit [Quit: This computer has gone to sleep]
16:00 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
16:00 -!- Shiftos [~shiftos@gateway/tor-sasl/shiftos] has joined #bitcoin-wizards
16:02 -!- Emcy [~MC@unaffiliated/mc1984] has quit [Read error: Connection reset by peer]
16:03 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving]
16:04 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 245 seconds]
16:10 -!- starsocc- [~starsocce@104.219.184.118] has joined #bitcoin-wizards
16:10 -!- starsocc- is now known as starsoccer
16:10 -!- starsoccer is now known as Guest60116
16:13 -!- jtimon [~quassel@147.pool85-53-220.dynamic.orange.es] has quit [Ping timeout: 255 seconds]
16:14 -!- Burrito [~Burrito@unaffiliated/burrito] has quit [Quit: INPUT ERROR: Too tired to keep eyes open!]
16:16 -!- Guest60116 [~starsocce@104.219.184.118] has quit [Ping timeout: 256 seconds]
16:18 -!- op_null [~op_null@128.199.56.23] has quit [Quit: leaving]
16:20 -!- Flyer9933 [~f@unaffiliated/fluffybunny] has quit [Ping timeout: 250 seconds]
16:21 -!- OneFixt [~OneFixt@unaffiliated/onefixt] has quit [Read error: Connection reset by peer]
16:21 -!- postpre [rs232@gateway/vpn/mullvad/x-toqovpzkknuhsdrz] has quit [Ping timeout: 250 seconds]
16:21 -!- OneFixt [~OneFixt@unaffiliated/onefixt] has joined #bitcoin-wizards
16:23 -!- Flyer33 [~f@unaffiliated/fluffybunny] has joined #bitcoin-wizards
16:25 -!- Flyer33 [~f@unaffiliated/fluffybunny] has quit [Excess Flood]
16:26 -!- Flyer33 [~f@unaffiliated/fluffybunny] has joined #bitcoin-wizards
16:39 -!- grandmaster [dansmith3@knows.the.cops.are.investigat.in] has quit [Remote host closed the connection]
16:41 -!- Emcy [~MC@unaffiliated/mc1984] has joined #bitcoin-wizards
16:45 -!- koeppelmann [~koeppelma@dyn-160-39-29-111.dyn.columbia.edu] has joined #bitcoin-wizards
16:46 -!- v3Rve [verve@i.am.on.irc.so] has quit [Read error: Connection reset by peer]
16:49 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection]
16:50 -!- koeppelmann [~koeppelma@dyn-160-39-29-111.dyn.columbia.edu] has quit [Ping timeout: 244 seconds]
16:53 -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards
16:55 -!- PRab [~chatzilla@c-98-209-175-70.hsd1.mi.comcast.net] has quit [Remote host closed the connection]
16:57 -!- postpre [rs232@gateway/vpn/mullvad/x-dcpxldisgvkjmsdf] has joined #bitcoin-wizards
16:58 -!- starsoccer [~starsocce@104.219.184.118] has joined #bitcoin-wizards
16:58 -!- starsoccer is now known as Guest12217
17:03 -!- Guest12217 [~starsocce@104.219.184.118] has quit [Ping timeout: 256 seconds]
17:03 -!- orik [~orik@remote.snococpa.com] has quit [Ping timeout: 265 seconds]
17:12 -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 252 seconds]
17:13 -!- Dizzle [~diesel@70.114.207.41] has quit [Quit: Leaving...]
17:18 -!- eordano [~eordano@162.243.147.96] has joined #bitcoin-wizards
17:19 -!- Grishnakh [~grishnakh@dsl-espbrasgw1-50dfb6-218.dhcp.inet.fi] has quit [Read error: Connection reset by peer]
17:27 < rusty> gmaxwell: so, would OP_SIDECHAINPROOFVERIFY use a genesis block id of the sidechain  as the sidechain identifier?
17:28 -!- eordano [~eordano@162.243.147.96] has quit [Quit: leaving]
17:32 -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards
17:35 < bramc> My impression is that op_sidechainproofverify is supposed to mostly check the amount of work done in the sidechain with very little other requirements on it. The paper does seem vague about it though.
17:35 -!- eordano [~eordano@162.243.147.96] has joined #bitcoin-wizards
17:35 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards
17:36 < sipa> the sidechain needs a transaction type that freezes/burns coins, which OP_SIDECHAINPROOFVERIFY understands
17:37 < gmaxwell> rusty: Yes, the proofs need to be rooted in the genesis block ultimately. though they could instead just prove they continued the chain last used in the last sidechain proof, which would makes them somewhat smaller.
17:37 < bramc> gmaxwell, Why do they need anything more than a transaction giving a destination for the utxo followed by an amount of work?
17:38 < gmaxwell> bramc: to show that the work had anything to do with the chain in question.
17:39 -!- woah [~woah@108-207-4-97.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards
17:40 -!- woah [~woah@108-207-4-97.lightspeed.sntcca.sbcglobal.net] has quit [Client Quit]
17:44 -!- user7779_ [user777907@gateway/vpn/mullvad/x-csjeubojlpylrafq] has quit []
18:01 < rusty> gmaxwell: OK, so bitcoind would maintain a sidechains set, which would only ever grow over time.
18:02 < Luke-Jr> rusty: the existing UTXO set works
18:03 < Luke-Jr> or could anyway, maybe it will end up being more efficient to specialise it
18:03 < gmaxwell> rusty: it's just a property of the coins assigned to the sidechain.
18:03 < gmaxwell> (e.g. just conditions in the scriptPubKey)
18:03 < sipa> using the UTXO set means that all sidechain transfers need to be serialized
18:04 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Quit: quit]
18:04 < gmaxwell> As you know, bitcoin doesn't track "ownership" but "conditions to release" and conditions get specified in the scriptpubkeys, so it fits nicely.
18:07 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-wizards
18:10 -!- ryanxcharles [~ryanxchar@162.245.22.162] has quit [Ping timeout: 250 seconds]
18:10 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
18:12 < rusty> So, a transfer back from the sidechain would consume N previous to-sidechain UTXOs in some defined order, and (optionally) produce an additional to-sidechain output (for change).
18:14 < Luke-Jr> or undefined order
18:17 < lechuga_> will it just be like coin selection in a wallet?
18:17 < rusty> Luke-Jr: True, but if you want to save utxos somewhere in the blockchain I think you need to define it, otherwise the new UTXO (the to-sidechain change) wouldn't be known?
18:18 < Luke-Jr> lechuga_: hopefully a bit smarter to avoid multiple attempts to claim the same UTXO
18:18 < gmaxwell> The code we've been working on basically lets you do a merge of sidechain coins without any proof. (basically a covenant on the output) so presumably you'd mostly issue proofless transactions to aggregate up the coins.
18:19 < Luke-Jr> gmaxwell: eh, if there's only ever one UTXO to claim, it kinda limits redeeming them
18:19 < Luke-Jr> although I suppose miners can combine multiple
18:19 < gmaxwell> Luke-Jr: you can redeem many at once.
18:19 < gmaxwell> (and I expect expect the sidechain itself to batch the redemptions)
18:20 < Luke-Jr> ah
18:20 < Luke-Jr> that's a good idea
18:23 -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has quit [Ping timeout: 265 seconds]
18:26 < rusty> gmaxwell: sweeping sidechain coins together is logical, but it seems like it has a commons problem: the miner who does it just expands their block, whereas the other miners benefit from the decrease utxo set size.
18:27 < gmaxwell> rusty: It benefits the sidechain, if you don't sweep you end up with enormous proof transactions spending many inputs (with many proofs), so someone who wants to emerge coins can reduce their cost of doing so by sweeping.
18:27 < gmaxwell> (and paying fees in the process)
18:31 < rusty> emerge?
18:31  * rusty is lost...
18:31 < gmaxwell> return coins from the sidechain.
18:32 < rusty> Right, so that tx would explicitly list the (to-sidechain) inputs it's spending?  I was assuming it was implicit, but I guess this is more bitcoiny.
18:32 -!- Starduster_ [~guest@unaffiliated/starduster] has quit [Read error: Connection reset by peer]
18:34 -!- koeppelmann [~koeppelma@dyn-160-39-29-111.dyn.columbia.edu] has joined #bitcoin-wizards
18:38 -!- belcher [~belcher-s@unaffiliated/belcher] has quit [Quit: Leaving]
18:39 -!- koeppelmann [~koeppelma@dyn-160-39-29-111.dyn.columbia.edu] has quit [Ping timeout: 244 seconds]
18:41 < Luke-Jr> rusty: iow, it's cheaper to have a transaction merging the sidechain UTXOs followed by redeeming one of them, than to redeem multiple
18:47 -!- licnep [uid4387@gateway/web/irccloud.com/x-kcxpfejgmloiyfqn] has joined #bitcoin-wizards
18:49 -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has joined #bitcoin-wizards
18:49 < rusty> Luke-Jr: Thanks, right.  This is because we're shoehorning it into the bitcoin prove-each-input-separately model.  If the inputs were implied, that would not be a problem.  We'd just have other problems :)
18:49 -!- jb55_ [~jb55@208.98.200.98] has joined #bitcoin-wizards
18:53 -!- jb55 [~jb55@208.98.200.98] has quit [Ping timeout: 258 seconds]
18:54 -!- jb55_ [~jb55@208.98.200.98] has quit [Ping timeout: 245 seconds]
18:54 < gmaxwell> the inputs model in bitcoin is pretty nice, it sort of magically solves a bunch of corner cases that smack you in the face (or ... stab you in the back, sadly more likely considering how easy it is to make mistakes) as soon as you move away from it.
18:56 < rusty> gmaxwell: OK, so continuing that model, a "oops, that was a fork" disproof would consume (all!) the "bad emerge" outputs?
18:59 -!- Netsplit *.net <-> *.split quits: midnightmagic
18:59 < gmaxwell> Yes.
18:59 -!- dansmith_btc [~dansmith@unaffiliated/dansmith-btc/x-0355117] has quit [Ping timeout: 258 seconds]
19:00 < rusty> gmaxwell: OK.  Would the OP_SIDECHAINPROOFVERIFY ScriptSig explicitly reference a tx output which proved a previous point in the sidechain?  Or would it have to prove it since one of its txins?
19:00 < rusty> gmaxwell: assuming we don't want an SPV-since-genesis every time.
19:00 -!- dansmith_btc [~dansmith@85.25.117.24] has joined #bitcoin-wizards
19:01 < gmaxwell> In that case it would just show that the linkage back to the block referenced in the prior proof (sort of changing along so it's still ultimately a proof to genesis, just spread over multiple transactions)
19:03 < rusty> gmaxwell: so, the highest-proven block has to be explicitly listed in the sweep txout (and others), otherwise you'd have to traverse back further when it was spent?
19:04 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-wizards
19:04 < rusty> ok, scratch (and others), since the others contains a proof which terminates at some block.
19:05 < rusty> I'm looking forward to seeing an actual implementation, or BIP.
19:08 < bramc> The paper does seem oddly vague on the details
19:09 < gmaxwell> It's considerably more detailed than the Bitcoin whitepaper. And it already was 20 something pages long.
19:09 < rusty> bramc: I agree.  It had some fascinating stuff, but it read more like a conglomeration than a focussed plan.
19:09 < gmaxwell> The actual mechenism details need to follow from the broader ideas, and also require a lot of public scrutiny to make sure the accomidate people needs are met.
19:10 < rusty> gmaxwell: true, it had to cover a fair bit of ground.  The section on SPV proofs was particularly ... unsatisfying.
19:11 < rusty> gmaxwell: but as someone who was actually implementing a "sidechain" at the time, a clear-cut plan would have been nice too :)
19:14 < gmaxwell> rusty: the other element is avoiding that computational security against review problem.  Ignoring attention constraints it could have kept the protocol mockup, but then people would fixate on that particular construction, and would be disinclined to review revised versions.
19:16 < gmaxwell> I mean, I think both of you failed to grasp that the proposal is just a soft fork change, though the paper says so directly in plain english. (and also has to explain what a soft-fork change is in order to do it).  Communicating is hard.
19:16 < gmaxwell> (failed initially, I mean, even after seeing the paper)
19:17 < rusty> gmaxwell: Yes, mea culpa.
19:19 < bramc> gmaxwell, I'm particularly not-practiced at reading papers and almost always have to ask questions about what they mean
19:20 < bramc> But I was just reading that paper again today having asked a bunch of questions by now because I wanted to see the specifics of the new opcode and was surprised that they're not there.
19:20 < gmaxwell> bramc: sorry, I wasn't trying to single you out. It's the papers fault it didn't communicate to everyone what it needed to. I was just rasing it to show that adding more details isn't free.
19:21 < gmaxwell> Like ... decribing the mechenism in general for a tech audience also sends you down a path of explaining how script works. And the Script as a generalization of script cryptosystems, and the atomic inputs model and...
19:22 < rusty> gmaxwell: I realized after that that I'd skimmed the paper after the first pages and the appendices, meaning to re-read, and didn't.
19:22 < lechuga_> communicating in code easier but more costly
19:23 < gmaxwell> code can be precise, but not clear. Especially without an understanding of the general idea to set the stage. :)
19:24 < gmaxwell> rusty: what about the SPV proof part were you unsatisfied with in particular?  It was an appendix in part because it's not core to the concept. Since at least conceptually it can work without the compact proofs (e.g. included every header incrementally in usage); though thats not very awesome.  Part of the challange in writing about that area is that its unclear exactly what should be the standar
19:24 < gmaxwell> d for resistance to luck. Pratically all work around bitcoin security in the past has totally ignored this angle.  (and, in fact, an attacker with an arbritarly low constant fraction of the hashrate, given infinite time in competition with the honest chain can replace the whole chain with probablity 1; if you assume that the hashrate has exponential growth forever... which is quite surprising, an
19:24 < gmaxwell> d wasn't published until a few months ago)
19:25 < gmaxwell> (this works out for the same reason that SPV proofs have _exactly_ the same expected work as the full header sets they stand in on but higher chance of getting lucky)
19:25 < rusty> gmaxwell: *that* part I loved.  I disliked that you didn't say which of the solutions you preferred :)
19:26 < rusty> (and I hadn't realized the issue with SPV proofs until I read that appendix, so it was eye opening)
19:28 < rusty> gmaxwell: BTW I was thinking that a sidechain could have a rule to allow to-bitcoin txs only in the block after a "short" SPV path back to the previous block-with-to-bitcoin-txs.  That would help optimize emerge proofs on the bitcoin side, though I haven't thought about whether it makes SPV fakery easier or not...
19:30 < gmaxwell> I think we'd swung back and forth at how much we cared about the variance attacks.  If you're adopting a security model where you demand everything to work if all the participants are greedy, then it's easy to discount negative expectation attacks.  ... But really that kind of security model is a massive oversimplification of reality (no less so than just stipulating that a majority will follow t
19:30 < gmaxwell> he protocol).
19:31 < bramc> gmaxwell, It seems like when things are put on a sidechain they're likely to have to be pulled off and put back on again from time to time just to reset the amount of work necessary to release them
19:35 < rusty> gmaxwell: For pettycoin I limited the number of prev blocks in the merkle, naturally limiting the SPV jumps and alleviating this problem.  Mainly because pettycoin has a horizon, and I didn't want SPV jumps back arbitrary distance (since you might not know that block header).
19:38 -!- jchp [~jchp@unaffiliated/jchp] has joined #bitcoin-wizards
19:39 < amiller> i have a nagging point of dissent about the sidechains roadmap: among the presented options for SPV proofs, one of them, the "ratchet" mechanism, is pedagogically much simpler than the others
19:39 < rusty> bramc: in practice I'm guessing sidechains would run using functionaries until they get over "Satoshi's Gap" (i.e. enough mining power to be difficult to exploit).   By then, there would be regular emerging, I'd expect.
19:39 < amiller> yet it's apparently fallen out of favor because it is not "scalable", to "millions of sidechains", under some assumptions about transaction volume between those sidechains and bitcoin
19:41 < rusty> amiller: dumb q: where is the "ratchet" mechanism presented?
19:41 < amiller> the alternative involves more moving parts such as interactive fraud challenges/proofs, so i think it's an overoptimization
19:42 < bramc> I still don't know what one might actually want to do with a sidechain, but that's a whole other issue
19:42 < amiller> "If we expect many transfers per sidechain, we can maintain a special output in the parent chain
19:42 < amiller> which tracks the sidechain’s tip. This output is moved by separate SPV proofs (which may be
19:42 < amiller> 630 compacted in one of the above ways), with the result that the parent chain is aware of a recent
19:42 < amiller> sidechain’s tip at all times.
19:44 < rusty> bramc: I wanted to do microtransactions.  But faster (and less variant) block times are another practical interest.
19:44 < jaekwon_> amiller: what is the ratchet mechanism?
19:45 < rusty> amiller: AFAICT that's an optimization of the above options, and approximated nicely by gmaxwell's sweeping transactions.  It's not a self-standing solution.
19:45 < amiller> i just pasted the "ratchet" paragraph from appendix B  (the word 'ratchet' isn't actually used, the conversation apparnetly comes from an old forum thread where it was discussed)
19:46 < amiller> rusty, well, it's not
19:46 < jaekwon_> For tendermint that's basically what I plan to do.  A special primitive that tracks the blockchain tip of sidechains.
19:46 < petertodd> amiller: "parent chain is aware of a recent sidechain’s tip" <- don't forget the data loss issue; there won't be just one tip
19:47 < jaekwon_> bramc: sharding onto pegged chains, as well as a mechanism for backing coins via an exchange mechanism.  tendermint.com/posts/sidechains-without-pegging/
19:47 < bramc> amiller, the stuff in appendix B seems sketchy. You need a huge number of samples to make an attacker unlikely to be able to get a big discount on work, big enough to make it seem implausible that there will be that many samples for quite a long time and just including the whole chain is smaller
19:47 < amiller> petertodd, right, i imagine there will be thousands or tens of thousands
19:47 < petertodd> amiller: no, I mean per sidechain there will be more than one
19:48 < amiller> petertodd, well the tip keeps advancing and old tips can be pruned away
19:48 < amiller> petertodd, creating a side chain would be similar to creating a single utxo, with similar overhead
19:48 < petertodd> amiller: you're still missing my point: from the parent's view a tip is just a link; but you don't have the data behind that link, so the structure allowed has to be a dag
19:49 < petertodd> amiller: otherwise I could advance that tip, never publish the block, and cause problems
19:49 < amiller> petertodd, you could do that with SPV proofs today
19:49 < amiller> against bitcoinj clients
19:50 < petertodd> amiller: yup, and they reorg when they see the longer tip - the consensus rules in the bitcoin blockchain therefore must allow multiple tips to exist for a given sidechain
19:50 < jaekwon_> rippling fork horrors
19:51 < amiller> petertodd, not quite
19:51 < amiller> petertodd, it needs a single tip at any given time, and you can extend that tip with a 'fork' as well
19:51 < petertodd> amiller: it's either that or they allow arbitrarily deep reorgs in the proof that advances that tip
19:51 < amiller> there isn't really anything wrong with allowing arbitrarily deep reorgs
19:52 < petertodd> amiller: no, but like I say, this does mean the notion of the "one" tip is kinda odd - ifit's a rachet where ever block header is put in the bitcoin chain for instance
19:52 < amiller> especially since deep reorgs are exponentially unlikely
19:52 < petertodd> amiller: it's a sidechain - it'll have shitty amounts o fhashing power on occasion, or often - lots of attack scenarios
19:52 < amiller> petertodd, the point is that you don't need to have a UTXO for every sidechain block
19:53 < amiller> anyway, the point is there are two main alternatives for the sidechain spv proof mechanism
19:53 < amiller> one of them involves these 'compressed' SPV proofs that always refer to the genesis
19:54 < amiller> you only need to create these proofs when someone actually withdraws a coin, which it's possible isn't very frequent if people prefer just to stay on the sidechain for a while
19:54 < amiller> however because of variance attacks, it's necessary to do this challenge response thing
19:55 < jaekwon_> any discussions yet on how to handle a pow algorithm hardfork for a sidechain?
19:55 < petertodd> the challenge response to establish if the proof really did represent a highest known total work right?
19:56 < bramc> amiller, that compression has a good asymptotic but very big constant factors, and always has to have some play in it
19:56 < amiller> petertodd, yes roughly
19:57 -!- Starduster [~guest@unaffiliated/starduster] has joined #bitcoin-wizards
19:57 < petertodd> and your comparing it to a rachet that puts some/all of the sidechain headers in the chain directly, correct?
19:57 < rusty> amiller: you *really* don't want to have to prove back to the genesis each time.  Every block header for a mergemined chain is order of 1k...
19:57 < amiller> petertodd, yes
19:57 < bramc> jaekwon_, I think it doesn't
19:58 < amiller> rusty, a proof back n blocks stlll only takes something like log n elments, it uses a skiplist kind of thing
19:58 < bramc> rusty, There's a clever trick which makes that a lot smaller, but I'm complaining that it doesn't really work that well
19:59 < gmaxwell> jaekwon_: it's pretty trivial, you'd handle it like and hardfork generally, sidechain would (according to its own rules) transfer all the coins to a new set of rules.
19:59 < bramc> gmaxwell, Doesn't the opcode for release have to understand the sidechain's proof of work?
19:59 < rusty> bramc: yes, a compact SPV proof.
19:59 < jaekwon_> right ^^
19:59 < gmaxwell> bramc: the proofs we give in the paper are substantially more efficent than the FST sampling proofs you were looking at that paper.
20:00 < petertodd> amiller: so like I say, with a rachet, remember you do need to account for the fact that the blocks associated with some chain may simply not be available - ugly economic attacks there
20:00 < bramc> gmaxwell, Yes but they still aren't all that great, and still have some play
20:00 < rusty> bramc: yes, but a sidechain of a sidechain is possible, hence a stepping-stone sidechain (which understands many different PoWs) is possible.
20:00 -!- coiner [~linker@42.115.148.180] has quit [Ping timeout: 240 seconds]
20:00 < gmaxwell> bramc: and in terms of the expected work they are immediately tight without any sampling at all. (but they have high variance as a side effect of their efficiency)
20:00 < jaekwon_> gmaxwell: i don't see how it's trivial, since as far as the mainchain can see, the old fork still has real bitcoins associated with it and can't know for sure (easily) that there was a hardfork.
20:00 < rusty> amiller: um, isn't that just a compact SPV proof then?
20:01 < jaekwon_> e.g. how does it know that the new sidechain fork is official?
20:01 < rusty> jaekwon_: it has more work?
20:01 < gmaxwell> jaekwon_: it requires the system to decide to move the coins, if some other incompatible system says it's owed the coins, thats called theft. :)
20:01 < jaekwon_> gmaxwell: which system, the mainchain system?
20:02 < gmaxwell> jaekwon_: the sidechain itself the original system.
20:02 < bramc> gmaxwell, Maybe I missed something, but I *think* the compact spv works by taking the root of a a merkle tree of the whole history, and then uses the bits of that root to generate challenges of which leaves have to have the paths to them revealed
20:03 < gmaxwell> jaekwon_: at any transfer the sidechain can change the rules for future validation the coins that come out as change.
20:03 < petertodd> gmaxwell: re: theft, is there any progress on the fact that the 2-way-pegs let miners with sufficinet hashing power steal coins at will?
20:03 < gmaxwell> bramc: No. Thats the fiat shamir transform approach, it's inefficient, and cannot prove a precise amount of work in the expectation.
20:03 < rusty> bramc: there was a good explanation somewhere in the forums when the original idea was proposed.  Let me see if I can find it for you...
20:03 < gmaxwell> rusty: you want maaku's post.
20:04 < gmaxwell> bramc: http://sourceforge.net/p/bitcoin/mailman/message/32111357/  (though I think the paper is even more clear than that)
20:05 < rusty> gmaxwell: I was actually thinking of https://bitcointalk.org/index.php?topic=98986.msg1083483#msg1083483
20:05 < petertodd> amiller: note btw how a rachet system with headers published in-chain gives the SPV users much better assurance they're not being sybil attacked
20:05 < petertodd> amiller: same proof-of-publication mechanism behind uniquebits
20:05 < gmaxwell> as far as the commitments go, ... if youre only going back to the genesis, you can use a very small number of commitments. But since the commitments are a hash tree, its stuidly cheap to use all of them and then you can easily jump to any block.
20:06 < gmaxwell> rusty: ah, well thats actually amillers old post which is something different and also cannot prove work in the expectation. (because there is no commitment)
20:06 < amiller> it's trivially modified so you can also get the 'in expectatoin' thing, if you want it
20:06 < amiller> a) "because there's no commitment" has nothing to do with the "in expectation" property, b) the "in expectation" property is kind of useless
20:08 < gmaxwell> amiller: The commitments are absolutely integral to that. In particular, it's essential if you want to use it to compare the difficulty between two honest chains, even absent any attacker at all, and always select the one that has the most cumulative work by the normal single stepping method.
20:08 < gmaxwell> (e.g. to actually instantiate the bitcoin chain selection algorithim)
20:09 < amiller> honest chains commit to their total work count, so it's totally fine to compare honest chains that way
20:10 < amiller> this is a digression, i don't think it matters much
20:11 -!- ryanxcharles [~ryanxchar@2601:9:4680:dd0:1106:c4e2:3499:7ec7] has joined #bitcoin-wizards
20:11 < amiller> even if you have a *fairly* precise proof about the total amount of work contained in a chain, it still doesn't reduce the variance that an attacker could extend a 1000000 block honest chain just a little bit, like 100 blocks, that's still enough to do a fraudulent spv spend or something
20:11 < amiller> which is why the compact SPV proof isn't enough on its own, you also do the challenge/response thing
20:12 < amiller> so, even with my data structure, or maaku's, or a combination of the two, you're still stuck with needing that interactive challenge/response thing
20:13 < gmaxwell> It's mine, incidentally. Not maaku's.
20:13 < amiller> ok
20:13 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards
20:13 < gmaxwell> amiller: depends on what you're considering the threat model. I don't see why you think it's not interesting and important that the expected work to create a fradulent proof is exactly equal to the expected work to create an honest one.
20:14 < gmaxwell> Since thats something of a prereq to making an incentives argument for a greedy/rational attacker.
20:15 < gmaxwell> If nothing else it gives you an assurance against DOS attacks.
20:15 < gmaxwell> wouldn't you agree with at least that?
20:15 -!- www [~glorius@92.226.185.46] has joined #bitcoin-wizards
20:18 < rusty> gmaxwell: I simulated this a while back, and a naive "jump back N when hash < target/N" doesn't give you log(blockheight).  It might be O(log(blockheight)), but it's not O(blockheight).
20:19 < gmaxwell> rusty: yea thats a dumb prover. :)
20:19 < rusty> gmaxwell: you're saying jump < N where it results in a shorter path, right?
20:19 < gmaxwell> rusty: the optimal path to genesis can be found in amoritized constant time (really linear time) via dynamic programming.
20:20 < gmaxwell> baslically for every block you keep track of how far from it it takes to get to genesis.  then for every new block you consider you consider each path you can reach and take the best path + distance to that path. and that becomes your cost to genesis.
20:21 < amiller> gmaxwell, "exactly equal" isn't a necessity, as long as it's close within some small fraction with high probability
20:22 < amiller> gmaxwell, either way, you can have both properties easily enough
20:22 < gmaxwell> rusty: and thats provably optimal.  Though it's only so cheap to compute when you only want a single destination. :)
20:23 < rusty> gmaxwell: indeed.  Coding it up now to check :)
20:23 -!- koeppelmann [~koeppelma@dyn-160-39-29-111.dyn.columbia.edu] has joined #bitcoin-wizards
20:23 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 244 seconds]
20:25 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards
20:27 -!- koeppelmann [~koeppelma@dyn-160-39-29-111.dyn.columbia.edu] has quit [Ping timeout: 240 seconds]
20:33 < rusty> gmaxwell: yep, that works.
20:34 -!- coiner [~linker@113.161.87.238] has joined #bitcoin-wizards
20:35 < gmaxwell> (FWIW, you suffer from being a noob: I'd mentioned that solution in here a long time back. :) )
20:37 < gmaxwell> One thing I did never solve was good strategies for including commitments to a subset of the blocks. If you're only interested in a path to genesis than immeidately you can eliminate all dominated hops (some earlier path back took you further), but beyond you should old need log() number of candidates to still keep log() behavior overall. But I never figured out an optimal approach for that.
20:37 < gmaxwell> since it's attractive to be able to go anywhere, and since adding more edges is cheap due to the hashtree it didn't seem worth giving it a ton of thought.
20:39 < rusty> gmaxwell: a side question, how do you derive amount of work from that proof?  Conservatively, you'd assume worst-case factor of 4 difficulty changes in fortnights you don't know.
20:40 < rusty> gmaxwell: which opens the possibility of a proof with more points demonstrating more work.
20:42 < gmaxwell> rusty: you include it in the commitments, which also limit how far back you can go.  e.g. your commitment says there existied a block one back with work 1 back to it, two back with work two back to it.. 2018 back with work 2019.2 back to it (difficulty changed), etc.
20:42 < rusty> gmaxwell: ah, OK.
20:42 < gmaxwell> and you can only skip back in proportion to your own solution lowness.
20:43 < gmaxwell> so claming there was more work in the gap doesn't help you _on average_ since it just makes it more likely you can't skip over your lie.
20:44 < rusty> gmaxwell: I think I like the solution restricting the distance jumped back, and tracing to any previous proof.  It's simple.
20:47 < bramc> What is the point of Counterparty?
20:48 < lechuga_> wall st on the blockchain
20:48 < gmaxwell> (1) create speculative asset (2) no step 2 is required. (3) profit ?
20:48 < lechuga_> so yeah
20:49 < bramc> I can't even tell what their technology does from their home page
20:49 < bramc> something about an alternative currency... which crams records into the bitcoin blockchain...
20:49 < gmaxwell> basically it's a competator to mastercoin.. it was announced later, but actually wrote some software earlier.
20:51 < gmaxwell> Both are, IMO, a little inexplicable. but they've been interesting sources of examples of interesting errors that happen when people write non-trivial things using bitcoin.
20:51 < bramc> Yeah, umm... I can't figure out what mastercoin does either
20:52 < bramc> something about using the bitcoin blockchain for communications?
20:53 < gmaxwell> They're basically altcoin systems but skipped the whole creating a p2p network part by packing data into bitcoin transactions. Avoiding systems programming allows innovation like ...  the first mastercoin software was written in visual basis. :P
20:53 < gmaxwell> er basic.
20:53 < bramc> gmaxwell, How do they prevent double spending without real integration?
20:53 -!- maraoz [~maraoz@181.29.97.171] has quit [Ping timeout: 264 seconds]
20:54 < gmaxwell> bramc: because your foo coins are also bitcoins (though of as small a value as the network will allow you to transact)
20:55 < bramc> what happens if somebody makes a transaction which mashes together a foo coin and a non-foo coin as inputs?
20:55 < gmaxwell> e.g. you have some 1e-8 bitcoin txout and by convention of your system (gleemed from tracing all its transactions through the bitcoin blockchain history) that 1e-8 btc is worth 100 foocoin.
20:55 -!- iang_ [~iang@skaro.afraid.org] has joined #bitcoin-wizards
20:55 < gmaxwell> bramc: system has some rules for dealing with it. I think in the case of mastcoin at least if you don't follow the rules (e.g. including the right goop in your transactions) the coin is just burned.
20:56 -!- bitbumper [~bitbumper@197.115.124.24.cm.sunflower.com] has quit [Quit: Leaving]
20:56 -!- grau [~grau@37.143.74.116] has joined #bitcoin-wizards
20:56 < bramc> It's got all the benefits of bitcoin, but proportionately much larger transaction fees?
20:57 -!- iang [~iang@skaro.afraid.org] has quit [Ping timeout: 256 seconds]
20:57 -!- iang_ is now known as iang
20:58 < gmaxwell> At least some of the benefits, but larger txn, so thus larger fees. Mastercoin's definition previously (I haven't checked later) required every transaction to pay mastercoin's creator some trivial amount. (I guess it still does: see the history on 1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P ). And then you also get fun like miners censoring the transactions, because its a competing currency and inefficien
20:58 < kanzure> bramc: i don't know about mastercoin, but counterparty does these things: https://github.com/CounterpartyXCP/counterpartyd/tree/224b56eb23824f0ed83c8088741f32664ce26233/lib/messages
20:58 < gmaxwell> t user of the blockchain space to boot.
20:59 < bramc> kanzure, that's a link to a bunch of source code
21:00 < kanzure> ah wait, how about this:
21:00 < kanzure> https://github.com/CounterpartyXCP/counterpartyd/blob/224b56eb23824f0ed83c8088741f32664ce26233/lib/blocks.py#L52
21:00 < kanzure> of course i'm linking to source code
21:00 < gmaxwell> yea, some of the applications they talk to are the same ones as colored coins, but instead cramming more data into the blockchain and requiring another speculative asset.
21:00 < kanzure> 20:49 < bramc> I can't even tell what their technology does from their home page
21:00 < kanzure> in general you should ignore all landing pages
21:00 < bramc> kanzure, even a pitch would be good, as in a high level description of value add
21:01 < kanzure> yeah those are usually fake
21:01 < kanzure> people can just say anything
21:01 < kanzure> source code is what you want to look at
21:02 < bramc> gmaxwell, leading to my inevitable next dumb question, what are colored coins?
21:02 < kanzure> there are many things that have been called colored coins
21:02 < kanzure> some exist more than others
21:03 -!- op_null [~op_null@128.199.56.23] has joined #bitcoin-wizards
21:03 < gmaxwell> Say you want your soul to be a tradable asset, split into lots of parts.  You could launch your own altcoin to track the ownership. But that seems pretty inefficient.
21:03 < kanzure> i believe the original idea of colored coins was about colored satoshis (non-fungibility)
21:03 < op_null> kanzure: I’m not convinced of that really. looking at the bitcoin source is a load more efficient if you actually know what’s going on. a good portion of it is meaningless as to the actual goal and design.
21:03 < kanzure> but now there are various OP_RETURN based things that claim to be colored coins
21:04 < gmaxwell> Instead you say here is a bitcoin It represents 1000 shares of my soul (imagine drawing on a dollar bill). and you define some convention for how the tracking uses the non-fungiblity of bitcoin to flow around through trades.
21:04 < kanzure> (mastercoin, counterparty, openassets, the list goes on) (and chromawallet is more the colored satoshi direction? i haven't read their source code yet)
21:05 -!- iang [~iang@skaro.afraid.org] has quit [Quit: iang]
21:05 -!- woah [~woah@199-241-202-232.PUBLIC.monkeybrains.net] has joined #bitcoin-wizards
21:05 < kanzure> oh am i supposed to list sidechains now when people ask about colored coins? i'm worried about the epistemics here.
21:06 < gmaxwell> bramc: which is all well and good; though since the utility of bramc's soul coins is ultimately tied to your willingness to back them ... one might ask the question as to what was actually accomplished here.   (it's not completely pointless, since it does take you out of the loop for trading ... but some of the applications people have dreamed up for this stuff is pretty tortured)
21:06 < gmaxwell> kanzure: hm? I don't think so. I certantly don't think of sidechains as colored coins... sidechains don't have any dependency on non-fungiblity, for example.
21:07 < gmaxwell> Though you could use sidechains to address some/most of the applications for colored coins. My impression is that most of the people talking about colored coins, or at least the ones who've been at it the longest, are mostly interested in the result: being able to digitize ownership information about a broader set of assets... the colored coin tracing stuff is just a mechenism.
21:08 < bramc> gmaxwell, if I wanted to create an exchange for bits of my soul where people had confidence that their transfers were happening and only had to worry about me doing eventual redemptions then this sounds like a good idea. But using colored coins for coloring bitcoins or some other completely meaningless currency seems ridiculous
21:08 < grau> gmaxwell: did I miss somaething obvious in my post on burn mining sidechains? I am a bit puzzled of no reaction. I's really appretiate a word.
21:08 < gmaxwell> (CC in bitcoin in the traditional formulation is a little ugly because there is no real way to make a SPV-like client for them, ... not unless we had a covenant functionality in script or explicit support for tracing other kinds of assets)
21:10 < gmaxwell> grau: hah. only 21 hours. I saw your post and though. "Hm Okay this deserves a considered reply, when I have the energy to actually think about it"
21:10 < grau> I am glad. that is enaough for now.
21:10 < grau> thank you
21:12 < gmaxwell> bramc: yes, I agree with you generally. But there is some suspension of disbelief related to "some other completely meaningless currency" in this space because creating 'completely meaningless currency' seems to be one of the most commonly used fundraising mechenisms around.
21:13 < bramc> gmaxwell, To be fair the same applies to bitcoin, but if you're going to do something new it should have some selling point to it beyond what bitcoin does
21:13 < bramc> And most of these things seem to solve 'problems' which aren't actually problems
21:14 < gmaxwell> bramc: In Bitcoin's case it was totally different from anything in existance already. And you get a limited supply 'thing' totally without a central issurer of any kind. This is pretty neat, but ... you only really need one of those. :)
21:14 < bramc> scrypt not being turing complete, for example, is not even vaguely a problem
21:14 < gmaxwell> script (I make that substitution too)
21:15 < bramc> I thought you said scrypt specifically to mean bitcoin script
21:16 < gmaxwell> bramc: yea, so ... I hope you can forgive some of the bad attitude about alt-thing-of-the-day thats powered by the same kind of 'oh come on' as those and other things. (also funny is many of the altthings that have tried to do something technical have emitted swiss cheese that was broken enough that there were no engineering lessons in them, only sociology lessons)
21:17 < gmaxwell> Oh no, bitcoin script is just called Script.  scrypt is the memory hard proof of work function created by the tarsnap person (C. Percival), which is used by litecoin in its hashcash.
21:18 < bramc> A good example of not sweating the details: Bitcoin's susceptibility to malleability is very easy to avoid if you're doing things from scratch. Hitting that was an understandable gotcha when bitcoin was first made, but it's well enough understood and simple enough that if you don't fix it in an altcoin you aren't trying to fix any actual problems
21:19 < op_null> as far as I know no altcoin has changed ECDSA signatures in Bitcoin from being DER encoded. low hanging fruit isn't the problem, it's just that fixing little technical quirks doesn't make for a good pump and dump.
21:19 < gmaxwell> (maybe I should say 'used by tenebrix' instead of litecoin)
21:19 < bramc> op_null, you don't even have to fix the encoding, you just have to make the utxos be referenced by transaction instead of transaction + hash
21:20 < bramc> er, transaction + signature I mean
21:20 -!- licnep [uid4387@gateway/web/irccloud.com/x-kcxpfejgmloiyfqn] has quit [Quit: Connection closed for inactivity]
21:20 < op_null> I meant the actual signatures, they are very wasteful in their encoding. they're 71 bytes rather than the ~65 they should be
21:20 < gmaxwell> bramc: maybe not that easy to avoid. For example, "miniblockchain" (another altcoin) advertised immune to malleability on its marketing material ... but it's not. it's a ground up rewrite, but they fixed malleability by basically eliminating the scripting system and having no complex serialization.
21:21 < bramc> gmaxwell, By the way there's been some interesting conversation in ##altcoin-dev which I moved over there to avoid getting on peoples's nerves
21:21 < gmaxwell> (but are still malleable because ECDSA is not a strong signature)
21:22 < bramc> gmaxwell, malleability isn't actually a problem if the transaction itself is fixed
21:23 < gmaxwell> Removing the witness (signature) is adequate. I think thats a fine thing to do.  I'm just pointing out someone sought to fix this and card enough to explicitly market it, and still got it wrong.
21:24 < op_null> bramc: what I was trying to get at is that people won't fix all of the little quirks because it's not really all that interesting. there's things that bug technical users like OP_CHECKMULTISIG getting a bit too frisky, but alas.
21:24 < bramc> gmaxwell, I understand the problem well enough to know that I have little confidence in my ability to well and truly remove malleability, which only increases the importance of removing the witness
21:26 < bramc> op_null, That's my point as well
21:26 < gmaxwell> bramc: the only downside I've come up with for this is that sometimes it has semantic or legal significance, so it still makes sense to explicitly commit to a particular value in blocks. (and obviously in the p2p network, if it uses the inv/ask pattern for flooding that bitcoin uses) but yes, I agree its an obvious design choice.
21:27 < bramc> gmaxwell, Yes the block which accepts the transaction should also specify the signature it relied on for the acceptance
21:27 < gmaxwell> (er s/card/cared/)
21:29 -!- paveljanik [~Pavel@unaffiliated/paveljanik] has joined #bitcoin-wizards
21:31 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
21:32 -!- grau [~grau@37.143.74.116] has quit [Remote host closed the connection]
21:33 -!- moa [~moa@opentransactions/dev/moa] has quit [Quit: Leaving.]
21:59 -!- EasyAt [~EasyAt@unaffiliated/easyat] has joined #bitcoin-wizards
22:12 -!- koeppelmann [~koeppelma@dyn-160-39-29-111.dyn.columbia.edu] has joined #bitcoin-wizards
22:12 -!- www [~glorius@92.226.185.46] has quit [Ping timeout: 245 seconds]
22:13 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
22:16 < rusty> op_null: re: "no altcoin has changed ECDSA signatures in Bitcoin from being DER encoded." Agreed, but pettycoin did!
22:17 -!- koeppelmann [~koeppelma@dyn-160-39-29-111.dyn.columbia.edu] has quit [Ping timeout: 272 seconds]
22:17 < op_null> I have no idea what that is
22:18 -!- Grishnakh [~grishnakh@dsl-espbrasgw1-50dfb6-218.dhcp.inet.fi] has joined #bitcoin-wizards
22:20 -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has quit [Ping timeout: 250 seconds]
22:22 < gmaxwell> A number of things are not DER encoded in fact.
22:22 < rusty> op_null: my sidechain project, before the word sidechain.  gmaxwell accused me of making an altcoin, so I'm glad there's now a known term for pegged not-bitcoins.
22:22 < gmaxwell> Miniblockchain isn't (and thought they were malleability immune, nope). IIRC the bytecoin/monero/things are just constant length serializations.
22:23 < gmaxwell> rusty: doesn't help that you called it 'pettycoin' :P
22:23 < op_null> gmaxwell: I sort of meant bitcoin clones, but I guess the mini block chain one fits in there.
22:24 < op_null> if you were re-writing bitcoin from scratch you obviously wouldn't make the same odd design choices
22:24 < gmaxwell> it's not a clone, its a rewrite.
22:24 < op_null> I could have sworn it was a heavy fork of bitcoin
22:24 < gmaxwell> Oh it wasn't _that_ odd, it's what the crypto library gave you. :)  "who am I to question the encryption black box?!"
22:26 < rusty> gmaxwell: xyz-coin is almost inescapable as a name.  These days I'd got for pettysidecoin or somthing.  Hmm, that sucks too...
22:26 < gmaxwell> pettybitcoin
22:27 < bramc> Maybe you could call it threefishcoin
22:27 < bramc> *rimshot*
22:28 -!- grau [~grau@37.143.74.116] has joined #bitcoin-wizards
22:31 < rusty> bramc: I guess that's a reference I wasn't supposed to get... ?
22:33 < bramc> rusty, The pgp team dumped AES in favor of threefish, because they were being petty
22:33 < rusty> bramc: that's... a stretch.
22:33 < bramc> It was really childish
22:34 -!- woah [~woah@199-241-202-232.PUBLIC.monkeybrains.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
22:34 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
22:35 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-wizards
22:35 < rusty> gmaxwell: IMHO pettybitcoin is a moral trademark violation; it kind of implies endorsement.
22:36 -!- Graftec [~Graftec@gateway/tor-sasl/graftec] has quit [Remote host closed the connection]
22:37 -!- Graftec [~Graftec@gateway/tor-sasl/graftec] has joined #bitcoin-wizards
22:37 < bramc> Maybe I should make a bitbitcoin
22:38 -!- Graftec [~Graftec@gateway/tor-sasl/graftec] has quit [Remote host closed the connection]
22:38 < gmaxwell> rusty: why is it that some people are so easily concerned with such matters, and other people see no problem calling their projects "bitcoin 2.0".
22:40 < rusty> gmaxwell: I always approached bitcoin as an interesting FOSS project.  Took me a while to realize that others have different motivations...
22:42 -!- Graftec [~Graftec@gateway/tor-sasl/graftec] has joined #bitcoin-wizards
22:44 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
22:44 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-wizards
22:52 -!- woah [~woah@199-241-202-232.PUBLIC.monkeybrains.net] has joined #bitcoin-wizards
23:02 -!- Netsplit *.net <-> *.split quits: midnightmagic
23:08 -!- Netsplit over, joins: midnightmagic
23:10 -!- grau [~grau@37.143.74.116] has quit [Remote host closed the connection]
23:16 -!- grau [~grau@37.143.74.116] has joined #bitcoin-wizards
23:19 -!- grau [~grau@37.143.74.116] has quit [Remote host closed the connection]
23:25 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 250 seconds]
23:50 -!- Graftec [~Graftec@gateway/tor-sasl/graftec] has quit [Ping timeout: 250 seconds]
23:50 -!- devrandom [~devrandom@gateway/tor-sasl/niftyzero1] has quit [Ping timeout: 250 seconds]
23:50 -!- eristisk [~eristisk@gateway/tor-sasl/eristisk] has quit [Ping timeout: 250 seconds]
23:50 -!- Dr-G2 [~Dr-G@gateway/tor-sasl/dr-g] has quit [Ping timeout: 250 seconds]
23:50 -!- Shiftos [~shiftos@gateway/tor-sasl/shiftos] has quit [Ping timeout: 250 seconds]
23:50 -!- mortale [~mortale@gateway/tor-sasl/mortale] has quit [Ping timeout: 250 seconds]
23:50 -!- TwoKoolFourSkewl [~TwoKoolFo@gateway/tor-sasl/twokoolfourskewl] has quit [Ping timeout: 250 seconds]