--- Log opened Sun Jan 04 00:00:13 2015
00:11 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
00:14 -!- lclc_bnc is now known as lclc
00:15 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 244 seconds]
00:17 -!- lclc is now known as lclc_bnc
00:18 -!- lclc_bnc is now known as lclc
00:32 -!- adam3us [~Adium@c31-67.i07-8.onvol.net] has joined #bitcoin-wizards
00:38 -!- cluckj [~cluckj@cpe-24-92-48-18.nycap.res.rr.com] has quit [Ping timeout: 255 seconds]
00:40 -!- kristofferR [~kristoffe@208.37-191-147.fiber.lynet.no] has joined #bitcoin-wizards
00:52 -!- vmatekole [~vmatekole@g227232254.adsl.alicedsl.de] has joined #bitcoin-wizards
00:57 -!- bosma_ [~bosma@S01067cb21bda6531.vc.shawcable.net] has joined #bitcoin-wizards
00:59 -!- op_mul [~op_mul@178.62.78.122] has joined #bitcoin-wizards
00:59 -!- adam3us [~Adium@c31-67.i07-8.onvol.net] has quit [Quit: Leaving.]
01:00 -!- bosma [~bosma@S01067cb21bda6531.vc.shawcable.net] has quit [Ping timeout: 240 seconds]
01:02 -!- adam3us [~Adium@c31-67.i07-8.onvol.net] has joined #bitcoin-wizards
01:05 -!- andy-logbot [~bitcoin--@wpsoftware.net] has quit [Remote host closed the connection]
01:05 -!- andy-logbot [~bitcoin--@wpsoftware.net] has joined #bitcoin-wizards
01:05  * andy-logbot is logging
01:11 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
01:15 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 245 seconds]
01:15 -!- bosma_ is now known as bosma
01:16 -!- bosma is now known as Guest40810
01:35 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:118d:3cda:742b:32c7] has quit [Ping timeout: 244 seconds]
01:42 < wumpus> curious that I hadn't heard of this before re: open source CPU architectures, a 64-bit one http://www.lowrisc.org/, the discussion on the tagged memory page also mentions CHERI
01:43 -!- Guest40810 is now known as bosma
01:48 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards
01:52 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Client Quit]
01:56 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards
01:56 -!- fanquake [~anonymous@unaffiliated/fanquake] has joined #bitcoin-wizards
02:11 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
02:11 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
02:15 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 245 seconds]
02:21 -!- MoALTz_ [~no@user-46-112-49-198.play-internet.pl] has quit [Quit: going back to sleep]
02:24 -!- kristofferR [~kristoffe@208.37-191-147.fiber.lynet.no] has quit [Quit: Textual IRC Client: www.textualapp.com]
02:32 -!- moa [~kiwigb@opentransactions/dev/moa] has quit [Quit: Leaving.]
02:34 -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards
02:42 -!- vmatekole [~vmatekole@g227232254.adsl.alicedsl.de] has quit [Remote host closed the connection]
03:00 -!- MoALTz [~no@user-46-112-49-198.play-internet.pl] has joined #bitcoin-wizards
03:08 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:118d:3cda:742b:32c7] has joined #bitcoin-wizards
03:10 -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has joined #bitcoin-wizards
03:11 -!- vmatekole [~vmatekole@g227232254.adsl.alicedsl.de] has joined #bitcoin-wizards
03:11 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
03:14 -!- e1782d11df4c9914 [~e1782d11d@cpe-66-68-54-206.austin.res.rr.com] has quit [Ping timeout: 244 seconds]
03:16 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 245 seconds]
03:18 -!- Profreid [~Profreitt@gateway/vpn/privateinternetaccess/profreid] has joined #bitcoin-wizards
03:19 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Ping timeout: 256 seconds]
03:19 -!- Guest19027 [~Pan0ram1x@095-096-084-122.static.chello.nl] has quit [Ping timeout: 240 seconds]
03:20 -!- e1782d11df4c9914 [e1782d11df@gateway/vpn/mullvad/x-qbelspgnotskqrfz] has joined #bitcoin-wizards
03:25 -!- Pan0ram1x [~Pan0ram1x@095-096-084-122.static.chello.nl] has joined #bitcoin-wizards
03:25 -!- Pan0ram1x is now known as Guest52336
03:28 -!- e1782d11df4c9914 [e1782d11df@gateway/vpn/mullvad/x-qbelspgnotskqrfz] has quit [Ping timeout: 240 seconds]
03:30 -!- e1782d11df4c9914 [e1782d11df@gateway/vpn/mullvad/x-eubqdwlmaglraihu] has joined #bitcoin-wizards
03:33 -!- lclc [~lclc@bothniafur.com] has quit [Changing host]
03:33 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-wizards
03:48 -!- d1ggy [~d1ggy@dslb-088-073-178-227.088.073.pools.vodafone-ip.de] has joined #bitcoin-wizards
04:11 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
04:12 -!- cluckj [~cluckj@cpe-24-92-48-18.nycap.res.rr.com] has joined #bitcoin-wizards
04:15 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 240 seconds]
04:18 -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Remote host closed the connection]
04:31 -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has quit [Ping timeout: 250 seconds]
04:37 -!- spinza [~spin@197.89.19.57] has quit [Ping timeout: 265 seconds]
04:37 -!- spinza [~spin@197.89.19.57] has joined #bitcoin-wizards
04:37 -!- spinza [~spin@197.89.19.57] has quit [Excess Flood]
04:38 -!- spinza [~spin@197.89.19.57] has joined #bitcoin-wizards
04:49 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:118d:3cda:742b:32c7] has quit [Ping timeout: 244 seconds]
04:52 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards
04:58 -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has quit [Quit: iang]
05:00 -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has joined #bitcoin-wizards
05:07 -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards
05:08 -!- hashtagg [~hashtagg_@69.23.213.3] has quit [Ping timeout: 255 seconds]
05:11 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
05:13 -!- spinza [~spin@197.89.19.57] has quit [Ping timeout: 240 seconds]
05:14 -!- spinza [~spin@197.89.19.57] has joined #bitcoin-wizards
05:14 -!- spinza [~spin@197.89.19.57] has quit [Excess Flood]
05:15 -!- spinza [~spin@197.89.19.57] has joined #bitcoin-wizards
05:15 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 245 seconds]
05:17 -!- hashtag_ [~hashtagg_@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards
05:17 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
05:19 -!- askmike_ [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
05:19 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Read error: Connection reset by peer]
05:21 -!- hashtag_ [~hashtagg_@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 240 seconds]
05:23 -!- askmike_ [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 240 seconds]
05:24 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
05:26 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Read error: Connection reset by peer]
05:26 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
05:29 -!- hashtag_ [~hashtagg_@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards
05:30 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 240 seconds]
05:33 -!- Arpp [~Arpp@gateway/tor-sasl/arpp] has joined #bitcoin-wizards
05:33 -!- Arpp [~Arpp@gateway/tor-sasl/arpp] has quit [Remote host closed the connection]
05:38 < e1782d11df4c9914> any serious implementations of MPC with respect to coinjoin anyone know of as being in development atm?
05:46 < op_mul> MPC?
05:47 < op_mul> oh right.
05:48 -!- d1ggy [~d1ggy@dslb-088-073-178-227.088.073.pools.vodafone-ip.de] has quit [Quit: Leaving]
05:49 < e1782d11df4c9914> sorry, multiparty computation with respect to coinjoin
05:49 < e1782d11df4c9914> are there any alts or bitcoin forks lying around in development? interested in the state of research
05:50 < op_mul> if you're looking for interesting cryptography altcoins really aren't the place for it. Monero/Bytecoin has some interesting stuff going on with ring signatures, which seems to be the exception.
05:51 < e1782d11df4c9914> right monero is what i was thinking of, but i'm not that interested in ring sigs, i understand its easier to implement than MPC, but i guess most of the research has been academic to date- just wondering if there were any whispers of ambitious implementers anywhere
05:53 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
05:55 < op_mul> I can't speak for what anybody else is doing.
05:56 < op_mul> as far as I can work out the trouble with coinjoin is always going to be peer discovery. no matter what you do, there's always going to be the danger of somebody flooding out your join with sybil joiners and discovering information about it.
05:59 < op_mul> you can't *lose* privacy that way, you just stand to gain none. you can't evaluate the quality of your privacy, either.
06:05 < e1782d11df4c9914> i havent researched the literature too deeply with respect to coinjoin specifically, but couldnt you construct a scheme that requires joiners to construct a proof towards a challenge to help discourage sybil joiners?
06:06 -!- askmike_ [~askmike@94.100.16.225] has joined #bitcoin-wizards
06:07 < e1782d11df4c9914> or at least construct some requirement that makes sybil joiners uneconomical with respect to inclusion within a join
06:07 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Read error: Connection reset by peer]
06:07 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
06:07 -!- askmike_ [~askmike@94.100.16.225] has quit [Read error: Connection reset by peer]
06:08 < op_mul> I'm not aware of any way of doing that
06:08 < e1782d11df4c9914> ok
06:08 < op_mul> any limiter you can come up with, I can scale to massive proportions
06:08 < op_mul> if it's burning money, sure, I won't be doing that, but people also won't want to use it
06:09 < e1782d11df4c9914> thats ok, just have to find some proof that makes it uneconomical to forge etc.
06:09 -!- askmike_ [~askmike@94.100.22.70] has joined #bitcoin-wizards
06:09 < op_mul> huh?
06:10 < e1782d11df4c9914> i'm sure some of the more dedicated minds have already thought of some alternatives, hopefully i can come back here with more discussion after some research
06:10 -!- vmatekole [~vmatekole@g227232254.adsl.alicedsl.de] has quit [Remote host closed the connection]
06:11 -!- askmike__ [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
06:11 < op_mul> finding a bottleneck to exploit is nearly impossible, or impossible.
06:11 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Read error: Connection reset by peer]
06:14 -!- askmike_ [~askmike@94.100.22.70] has quit [Ping timeout: 250 seconds]
06:22 -!- zooko`` [~user@c-75-70-204-109.hsd1.co.comcast.net] has joined #bitcoin-wizards
06:24 -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has joined #bitcoin-wizards
06:28 -!- wallet421 [~wallet42@g226057074.adsl.alicedsl.de] has joined #bitcoin-wizards
06:28 -!- wallet421 [~wallet42@g226057074.adsl.alicedsl.de] has quit [Changing host]
06:28 -!- wallet421 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards
06:28 -!- wallet42 is now known as Guest25452
06:28 -!- Guest25452 [~wallet42@unaffiliated/wallet42] has quit [Killed (tepper.freenode.net (Nickname regained by services))]
06:28 -!- wallet421 is now known as wallet42
06:31 -!- zooko`` is now known as zooko
06:32 -!- coiner [~linker@42.116.152.78] has joined #bitcoin-wizards
06:39 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:118d:3cda:742b:32c7] has joined #bitcoin-wizards
06:39 -!- NewLiberty_ [~NewLibert@2602:304:cff8:1580:118d:3cda:742b:32c7] has joined #bitcoin-wizards
06:45 -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Remote host closed the connection]
06:47 -!- NewLiberty_ [~NewLibert@2602:304:cff8:1580:118d:3cda:742b:32c7] has left #bitcoin-wizards ["Leaving"]
07:00 -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has quit [Quit: iang]
07:31 -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
08:21 -!- torsthaldo [torsthaldo@gateway/vpn/mullvad/x-wbdjumzpdljtngib] has joined #bitcoin-wizards
08:21 -!- torsthaldo [torsthaldo@gateway/vpn/mullvad/x-wbdjumzpdljtngib] has quit [Client Quit]
08:24 -!- vmatekole [~vmatekole@g227232254.adsl.alicedsl.de] has joined #bitcoin-wizards
08:24 -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has joined #bitcoin-wizards
08:24 -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has quit [Client Quit]
08:27 < Taek> <justanotheruser> Sorry if this has been covered, but is storj following the original idea? If so, why does it need its own blockchain?
08:27 < Taek> <jgarzik> justanotheruser, it is not following the original idea at all
08:27 < Taek> What is the original idea?
08:29 -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has joined #bitcoin-wizards
08:34 -!- fanquake [~anonymous@unaffiliated/fanquake] has left #bitcoin-wizards []
08:38 < sipa> ask gmaxwell
08:40 < Taek> relevant: http://garzikrants.blogspot.com/2013/01/storj-and-bitcoin-autonomous-agents.html
08:42 < jgarzik> ^
08:43 < Taek> seems like the original idea was not decentralized?
08:44 < Taek> as in, the storj code that's serving storage had to be run on trusted hardware, is only run in one place, and the customer has to figure out if the storj instance is trustworthy/
08:44 < Taek> *?
08:46 -!- a5m0 [~a5m0@unaffiliated/a5m0] has quit [Quit: No Ping reply in 180 seconds.]
08:47 -!- a5m0 [~a5m0@unaffiliated/a5m0] has joined #bitcoin-wizards
08:48 < jgarzik> Taek, the original idea has nothing to do with altcoins
08:49 < adam3us> Taek: I dont see why you need an alt.  probably they dont, which means its an appcoin.  ie why do you think the storj ICO holders can expect the p2p users on the network to pay economic rent to the ICO holders.  they cant so what will happen in reality is someone will fork the network and pay for services at market rates in bitcoin.
08:50 < Taek> I don't claim to know very much about stroj the altcoin, I've never properly groked their whitepapers
08:51 < Taek> but a nice feature of storage is an automatically enforced contract that penalizes a host if they can't prove they have the file
08:51 < adam3us> Taek: havent read them. but sometimes when it makes your head hurt its because it doesnt compute :)
08:52 < op_mul> I don't understand why people would want to use storj in it's current form
08:52 < op_mul> you pay people to store files you already have on your disk, and you've got to keep uploading them again to the network to repair it. might as well just buy some storage somewhere proper.
08:53 < adam3us> Taek: its an observation that there are more things that it'd be nice to be able to robustly prove in a distributed system than we know how to enforce.  (and when you put fungibility money on top of it people are going to sysmtematically abuse any gaps in enforceability)
08:54 < Taek> we know how to make someone prove they have a file in a decentralized context
08:54 < adam3us> Taek: i suspect most of these systems have that a) because its hard or in some cases impossible; and b) mostly they are enthusiastic or have their eye on marketing the ICO or coin pump more than coding; and c) they mostly dont know what they're doing.  (hence the white papers are mostly technobabble as gmaxwell calls it)
08:55 < op_mul> Taek: well, that's sort of sticky. you can ask someone to prove *somebody* has a copy of a file, you can't prove a particular person has it.
08:55 < Taek> "these systems have that" --> what is that?
08:55 < adam3us> Taek: well can it be proxied for example?  can i pay someone a tiny payment to answer the question i relay them?
08:55 < adam3us> Taek: technobabble
08:56 < Taek> do you care if the answer is proxied? As long as someone has your file you should be happy
08:56 < adam3us> Taek: well you do if you're paying for redundancy
08:56 < Taek> if you're worried about redundancy, you should encrypt a bunch of pieces after you encode them
08:56 < op_mul> Taek: that's where all of these systems of "pay full nodes" fall down, which is a similar sort of concept. people want to pay nodes for storing data, but there's no way to prove they actually are.
08:57 < Taek> that way someone can't cheat by pretending to have multiple copies - they don't know how to decode the redundant files
08:57 < adam3us> Taek: getting better, but now you're designing it for them.
08:57 < op_mul> that doesn't prove many people have it though.
08:57 < Taek> adam3us: designing it for storj?
08:57 < op_mul> they could all be just me, and therefor the "redundancy" is worthless.
08:57 < adam3us> op_mul: Taek means that you'd secret share it with high redundancy and hten store the unique shares once each
08:58 < op_mul> if I had some magic cheap storage, sybiling the storj network would presumably be profitable.
08:58 < adam3us> Taek: i dont know how storj works actually.
08:58 < op_mul> adam3us: they do something like that. encrypt the chunks uniquely for each host.
08:58 < adam3us> op_mul: bingo.  the hard part is compactly proving storage.
08:58 < Taek> op_mul: sybil attacks would be a concern. There are ways to mitigate that but no golden bullet
08:58 < op_mul> yes, they do a challenge response system with "heatbeats".
08:59 < op_mul> Taek: no there's not :)
08:59 < adam3us> Taek: mitigate = systematically abused.
08:59 < Taek> ie each host locks coins away for a few moths to add weight to themselves
08:59 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 245 seconds]
08:59 < Taek> adam3us: what do you mean by that?
08:59  * op_mul giggles
08:59 < op_mul> every solution is the masternode one now, eh? :)
09:00 < adam3us> Taek: say you want something to work but it doesn quite.  so you patch it up a bit ofr obvious things that occur to you.  you put fungibile money on top of it, some hacker makes swiss cheese of your "patch it up" stuff and brings the system down
09:00 < Taek> I don't think masternode was the first one to have that idea. You wouldn't trust consensus to people with more storage, only files
09:01 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards
09:01 < adam3us> Taek: one way to compactly prove storage is to request a fiat-shamir transform over it with your challenge.
09:01 < adam3us> Taek: i presume thats what the jgarzik / gmaxwell post is about.
09:02 < Taek> I think that one requires someone who already has the data to pose the challenge right?
09:02 < jgarzik> adam3us, StorJ as envisioned in the blog post an autonomous agent
09:02 < adam3us> Taek: yes thats the problem
09:02 < jgarzik> adam3us, not much to do with storage proofs or decentralization
09:02 < jgarzik> *is an
09:03 < Taek> There's a weaker alternative using merkle trees. You can't make them prove they have the whole file but you can make them prove they have a segment, and anyone can pose the challenge
09:03 < Taek> Ask for 1 random segment a day, and after a few weeks you're pretty convinced they have 99%+ of the data
09:03 < op_mul> so? that's only proof for you
09:04 < op_mul> that's a hell of a lot of data if every node is asking for proof of every chunk
09:04 < adam3us> Taek: i presume you're talking about this http://storj.io/ and that yo're saying it has an alt or ICO behind it?
09:05 < op_mul> adam3us: yeah, they did some annoying crowd funding thing and made bank.
09:05 < Taek> what is ICO?
09:05 < op_mul> adam3us: http://storj.io/crowdsale.html
09:05 < sipa> Taek: initial coin offering
09:05 < adam3us> Taek: marketing/branding for premine / presale
09:05 < Taek> ah
09:07 < adam3us> Taek: there's a paper by coelho on a proof of work using storage.  vitalik had a go at tweaking it as dagger.  (still has tmto so he abandoned it)
09:07 < kanzure> so since nobody has figured out a way to prove redundancy or anything, isn't this a principle agent problem for people running data centers or hosting services (like s3)?
09:07 < sipa> tmto?
09:07 <@gmaxwell> Taek: " you can make them prove they have a" no you can't. You can have someone prove they have a segment, but its fully delegatable.
09:07 < op_mul> time memory tradeoff
09:07 < adam3us> Taek: its related to proof of storage: http://hashcash.org/papers/merkle-proof.pdf
09:08 < op_mul> sipa: I like ToMaTO as a term for that though.
09:08 < sipa> TiMeTO, you mean?
09:08 < kanzure> gmaxwell: i wonder if you could make the delegation obvious, or in such a way that relays/delegation can only pass on the original response, and not modify the pay-to info
09:08 < Taek> you say TiMeTO I say ToMaTO
09:09 < op_mul> sipa: ToMaTO makes sense as a joke about the fruit though. TiMeTO is just odd.
09:09 < adam3us> kanzure: they could ip-forward your request.
09:09 <@gmaxwell> kanzure: sure you can make things where you can't secretly delegate... but mining in bitcoin is a sybil resistance mechnism, which storage queries can't substitute.
09:10 <@gmaxwell> kanzure: I mean you can't make it secret from the party recieving the request.
09:11 < Taek> why is it important if the service you are talking to is the service controlling the data?
09:11 < adam3us> gmaxwell: maybe you could prove the miner knows a private key.  i think monero tries to do that maybe
09:11 <@gmaxwell> kanzure: e.g. if the requests are always pseudorandom the request is H(nodeid||nonce) % range.
09:11 <@gmaxwell> Taek: because the optimal solution otherwise is for there only to be one copy of the data.
09:12 < adam3us> you know one of these years an alt will invent something.  maybe. perhaps.
09:12 <@gmaxwell> Taek: and if you've made this part of the incentives in a consensus system, the optimal solution is that one-archive starts filling the network with 'files' that contain nothing but H(secret||counter) which it, knowing the secret, can answer super cheaply without storing.
09:12 < kanzure> how did that "proof of deletion" thing work? /me looks
09:13 < kanzure> http://diyhpl.us/~bryan/papers2/bitcoin/Deleting%20secret%20data%20with%20public%20verifiability.pdf
09:14 < Taek> gmaxwell: only a problem if you're using storage as your means of consensus. Something I was trying to do a while ago but have since abandoned
09:14 <@gmaxwell> adam3us: monero doesn't... and I don't think that helps, because the big disk could just be an unbounded number of identites.
09:15 <@gmaxwell> Taek: I did say 'if', not because I had any knoweldge of you not doing that; but because it was promoted and I know it to be broken.
09:17 -!- lclc is now known as lclc_bnc
09:18 <@gmaxwell> kanzure: that proof of deletion isn't what it says it is. It seems to be a "I promise I'm deleting key x -- bob" such that if you later see anything decrypted with key x, you know it lied.
09:18 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Quit: Leaving]
09:19 <@gmaxwell> should be called "promise of deletion" not "proof of deletion" :P
09:21 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-wizards
09:22 < Taek> so, assuming you can't solve delegation, you can still have worthwhile proof of storage by encrypting your redundant copies before uploading them
09:23 < Taek> you have to be around to make your own repairs, but if you pick a high enough redundancy you don't have to be around often
09:23 < Taek> and some redundancy schemes mean you don't even need the whole original file to make repairs: http://arxiv.org/pdf/1005.4178.pdf
09:25 <@gmaxwell> Taek: yes, you can add redudancy but if there is no reason for it to be stored on multiple systems it may not be meaningful redundancy. (worse, it's hidden from you how non-redundant it is)
09:26 < adam3us> Taek: i imagine if you can repair it you can compact it while removing redundancy and then simulate the redundancy in answer to the proof of storage and store more cheaply (but less redundantly)
09:28 -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards
09:28 <@gmaxwell> adam3us: yes, thats solved by making everyone unable to repair it.
09:28 < adam3us> Taek: and you need pretty high redundancy if you're storing in a p2p network with churn.
09:29 < adam3us> gmaxwell: but then he's back to having to be around to repair his own files.
09:35 -!- vmatekol_ [~vmatekole@f055081095.adsl.alicedsl.de] has joined #bitcoin-wizards
09:36 < Taek> I imagine you'd want redundancy for any data you plan on storing, but it's true that you'd be uncertain about how much geographic redundancy you're getting. You'd know the phyiscal data existed N times but it could all be on the same platter
09:36 <@gmaxwell> adam3us: which is what he said. :)
09:36 <@gmaxwell> Taek: would be, because the system is vastly more efficient if there is only one copy.
09:37 < Taek> but also very unstable. I believe the general rule of thumb for corporations is 3 copies
09:37 -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has quit [Quit: iang]
09:38 -!- vmatekole [~vmatekole@g227232254.adsl.alicedsl.de] has quit [Ping timeout: 255 seconds]
09:38 < adam3us> gmaxwell: yeah that was a little circular.
09:39 < adam3us> gmaxwell: at least i guess its clear it would be desirable to have the network able to repair, and not able to reduce redundancy while still collecting full storage fees, tho we dont know how to do that or if its possible.
09:40 < adam3us> Taek: yeah what gmaxwell was saying up a bit was it'd all end up on one disk.
09:42 -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Remote host closed the connection]
09:42 < op_mul> adam3us: I don't think it's possible, myself.
09:42 < Taek> I think in practice there would be enough ways for a client to get the data in multiple places. You'd likely be falling back on layer 8 processes, but since the client is manually choosing who to rent storage from, it's not consensus critical
09:50 < michagogo> Is it theoretically possible (yes, I know it's unlikely enough to the point that it may as well be considered impossible) to have 256 bits that SHA256 to themselves?
09:51 < op_mul> I don't see why not.
09:52 < op_mul> not sure we know if any given output is actually possible or not though
09:52 < adam3us> Taek: this is starting to sound less like a p2p system, with built in incentive or m2m fee based renting that you could let run without human intervention.  a hacker is going to get in there and rob the renters blind :)
09:52 < sipa> michagogo: if it's a perfect random function, there is 63% chance for that :)
09:52 < sipa> (1-1/e)
09:54 < adam3us> op_mul: well maybe.. if u admit enough snark, obfuscation & fully homomorphic encryption
09:54 < adam3us> op_mul: tho possibly not simply and not now
10:03 -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards
10:05 -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Remote host closed the connection]
10:11 -!- jtimon [~quassel@34.pool85-59-141.dynamic.orange.es] has quit [Ping timeout: 250 seconds]
10:15 < Taek> adam3us: m2m?
10:18 -!- jtimon [~quassel@16.pool85-53-130.dynamic.orange.es] has joined #bitcoin-wizards
10:20 -!- eudoxia [~eudoxia@r167-56-16-102.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards
10:24 < op_mul> adam3us: even if it worked I question the utility of such a service.
10:25 -!- coiner [~linker@42.116.152.78] has quit [Ping timeout: 250 seconds]
10:26 < adam3us> op_mul: people pay amazon for storage, they have some geo-redundant options also.  there are some p2p storage things that are a bit like this, though they dont try to be byzantine secure nor necessarily central control-free.
10:26 < Taek> op_mul you could end up with somelike like Uber or Airbnb for storage, where lots of small parties collaborate to make something a lot more effective than a giant alternative
10:27 < adam3us> op_mul: i used to work for mozy (well emc/vmware who bought mozy) who had a 50PB cloud storage and analysed a number of related systems including p2p ones.
10:27 < adam3us> op_mul: eg spideroak (not p2p), then there's zooko's tahoeLAFS which is p2p, and another one or two who's names i forget
10:27 -!- coiner [~linker@42.116.152.78] has joined #bitcoin-wizards
10:28 < op_mul> who cares if storage is p2p or not. peer to peer and decentralised systems are inefficient and expensive. I'd trust amazon glacier for backups more than I would any of these half baked IPO nonsense altcoins.
10:28 -!- coiner [~linker@42.116.152.78] has quit [Max SendQ exceeded]
10:29 < op_mul> if you encrypt your backups, it doesn't matter where they are stored so long as they exist in some form.
10:30 < Taek> and as long as nobody decides to change their terms, jump their prices, or discontinue your service w/o refund for violating obscure TOS
10:30 < adam3us> op_mul: well indeed ICO nonsense coins.  but tahoeLAFS for example is pure p2p and existed before bitcoin and has no alt associated.  i presume its sort of tit-for-tat economics like bittorrent.
10:32 < adam3us> op_mul: the argument however may work in that amazon is arguably not that cheap in bulk if you're storing a lot and p2p could provide it cheaper.  there was also spacemonkey.com by a few ex-mozy guys https://www.spacemonkey.com/ that has an economic model (no altcoin, you pay for a service and you get the hw discounted)
10:32 < adam3us> op_mul: with spacemonkey the p2p cloud is made by unused storage in the drives
10:34 < op_mul> adam3us: there's no reason to make things decentralised unless they absolutely need to be. the inefficiencies make it quite undesirable.
10:36 < Taek> op_mul: decentralized perhaps not, but p2p is a different story. If you want to build 10,000 small datacenters in the US it's going to be very expensive, but if you're doing p2p you get that as a side effect
10:37 < op_mul> I don't really follow there.
10:38 < Taek> In a system of p2p storage, you have hundreds to thousands of nodes distributed all over the world
10:39 < Taek> the distribution can be leveraged to get massive parallelism, and to keep files in a place that's geographically closest to you
10:39 < Taek> (disregarding byzantine attacks)
10:39 < op_mul> lots of small nodes to me just says inefficiency.
10:39 < Taek> everyone has multiple nodes within 50ms
10:40 < Taek> it's a lot cheaper to move bandwidth from idaho to idaho than it is from Seattle to idaho, or Ireland to idaho or wherever your massive datacenter is
10:41 < Taek> and you get much stronger geographic redundancy
10:42 < op_mul> I have no idea where those cities are. quite often you're not going to get people physically close to each other having a direct path. sometimes your file will go hundreds of KM off to some hub and then back again.
10:42 < op_mul> I don't think, in that sort of situation, bandwidth cost is even a factor.
10:42 < Taek> it's something that you can nonetheless optimize better if you have many small nodes as opposed to few large nodes
10:42 <@gmaxwell> Taek: it's actually not always cheaper to move data short distances, it's cheaper to move data between hubs, because capacity costs scale by the muxing width.  E.g. It's (much) cheaper to have 100GBit/s to one fairly far destination then it is to have 1GBit/s connectivity to 100 moderate distance desitnations.
10:43 < Taek> hmm
10:43 <@gmaxwell> Cost per megabit in the last mile is orders of magnitude higher than it is at the centers of networks.
10:43 < op_mul> and I'd have my gigabit port over 100 ADSL customers connections any day of the week.
10:44 < adam3us> gmaxwell: and that argues for what op_mul is saying - its inherently bandwidth inefficient to use p2p storage.
10:44 -!- jtimon [~quassel@16.pool85-53-130.dynamic.orange.es] has quit [Read error: Connection reset by peer]
10:44 < adam3us> gmaxwell: the datacenter bw is way cheaper & you need higher redundancy because of peer churn.  lose^2
10:45 -!- jtimon [~quassel@16.pool85-53-130.dynamic.orange.es] has joined #bitcoin-wizards
10:45 <@gmaxwell> yea, it is. It may achieve some 'useful' cost externalities (e.g. foolish providers who've sold all you can eat plans that are waiting to be exploited), but such solutions are not inherently stable since people often consider you a problem when you exploit the deal they gave you. :)
10:45 < adam3us> gmaxwell op_mul and yet still bittorrent is still using the most bandwidth of any protocol clogging those slow /expensive ast mile links
10:46 < Taek> is this wrong: with central nodes you travel the last mile once, but with p2p you travel it twice? Is it bounded at twice?
10:47 <@gmaxwell> bramc probably does not recall, but many moons ago when bittorrent was new and I ran a public network; I wasted some number of cycles with him arguing that bittorrent should be more topology aware, because as designed it was very abusive of expensive last mile links, and it was going to cause providers to block/rate limit it because it'll break their networks. :P   ("I told you so.")
10:47 <@gmaxwell> (though I think providers turned out to be less agressive than I expected, to be fair.)
10:47 < adam3us> Taek: probably. and with bittorrent you travel it hundreds of times
10:47 < adam3us> gmaxwell: if the isps knew what was good for them they'd install a mega torrent cache.
10:47 <@gmaxwell> Taek: no, it's not just twice, its that the fact that you could _choose_ to go down any of many paths means that all paths have to have the capacity.
10:48 <@gmaxwell> adam3us: yes, **ahem** some people went into business selling tools for caching and shaping after it became an issue; though it seems throttling it cheaper to deploy.
10:49 < adam3us> gmaxwell: hearn was talking about micropayment hosted file sharing to kill bitcoin.  i had mentioned to him that he should maybe talk to bram about using it to improve tit for tat in bittorrent.
10:49 < op_mul> Taek: the topography can be wildly different just depending on where it is. I know of one setup where houses in the same town have a 100ms, hundreds of kilometers round trip. in that case a P2P connection is going to have quite an impact.
10:49 <@gmaxwell> Taek: costs in networks are related to the potential capacity, not the actual used capacity.
10:49 < wumpus> adam3us: content-addressable-storages at hubs would be a nice optimization of the internet, I vaguely remember some plans, but I guess the economics doesn't work out
10:51 < Taek> gmaxwell: in p2p is that a fair assessment? When you build a p2p network you assume the infrastructure is already in place and doing other things. You make use of the already existing capacity instead of building out more.
10:51 -!- askmike__ [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Remote host closed the connection]
10:52 < Taek> op_null: the other advantage to p2p/decentralization is that (in theory) it forces the price much closer to at-cost
10:52 < Taek> right now, if I want to compete with s3, I need to build a reputation and grab customers
10:53 < Taek> but on Bitcoin, if I want to compete with a mining rig, I just have to plug in my cheaper hardware, no need to find customers
10:54 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
10:55 <@gmaxwell> Taek: consider two cases: one where things are p2p and one where its client/server-ish. Say the usage increases and links are strained. In client/server there is one hotspot where you can put your upgrade costs, in p2p you have to upgrade many last mile links.  If the p2p was a spherical cow of perfect topology awareness and unbounded adaptivity, then I suppose you could purely upgrade some serve
10:55 <@gmaxwell> r exactly like in the client/server model and it would figure it out, but real systems aren't like that.
10:55 < wumpus> adam3us: I can't remember what it was called, but the realisation was that most of internet traffic is indeed the same files all over again, it involved clients requesting blocks of data by their hash, which are cached by intermediate parties as necessary
10:55 <@gmaxwell> Worse, this traffic competes with other traffic which can't just move elsewhere... so for a low priority p2p thing it might be okay to just let the links saturate to all hell, thats not okay for the other traffic sharing the links.
10:56 -!- user7779078 [user777907@gateway/vpn/mullvad/x-cyvyoejhorzmrxib] has joined #bitcoin-wizards
10:56 -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards
10:56 -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Remote host closed the connection]
10:57 <@gmaxwell> (it doesn't help that BT doesn't use erasure coding, so you can very easily bottleneck on a single piece. :( )
10:57 <@gmaxwell> (freenet does much better, ignoring the fact that it's freenet and thus hardly works.)
10:57 < op_mul> gmaxwell: ugh man not again. now I've got that song stuck in my head again.
10:58 < op_mul> https://www.youtube.com/watch?v=eSMeUPFjQHc < every time you say erasure coding.
10:59 <@gmaxwell> I have a couple erasure albums around here someplace.
11:00 < Taek> gmaxwell: in my sphereical cow world, when two pieces of data are fighting for the same link, they compete on price and the one offering a higher payment gets higher priority. Humans can then tell where to add new lanes to maximize profit and can move p2p data to nodes with cheaper bandwidth
11:00 < Taek> perhaps it wouldn't work so well in practice
11:00 < zooko> Hey folks, Tahoe-LAFS is related to your apparent interests.
11:00 < zooko> However, I can't stay to read backlog carefully and chat because I have a date (!?!). :-)
11:01 < sipa> zooko: reading backlogs and chatting while having a date is totally in
11:01 < zooko> Haha
11:02 < Taek> if it's anything like my last date you can be buried in #wizards while she's buried in her facebook feed
11:02 -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has quit [Quit: you guys are trying to make me late for my date!]
11:02 < fluffypony> hah hah Taek
11:04 < wumpus> adam3us: oh, found it: that project is called CCNx
11:04 -!- epoche [~Glyphnote@2600:1004:b013:9f11:a46c:e148:441f:9ef9] has joined #bitcoin-wizards
11:17 -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has joined #bitcoin-wizards
11:20 -!- askmike_ [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
11:20 < phantomcircuit> op_mul, how does one even construct a network in which there's 100ms rtt between physically close
11:21 < phantomcircuit> nodes
11:21 -!- askmike_ [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Read error: Connection reset by peer]
11:21 < phantomcircuit> are there like 2 isps which dont have a peering point in town?
11:21 -!- askmike_ [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
11:21 < op_mul> phantomcircuit: yep, exactly.
11:22 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 250 seconds]
11:23 <@gmaxwell> phantomcircuit: thats the topology you get when you block adjcent port traffic so you can enabled "lawful intercept", hurrah.
11:23 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
11:23 < phantomcircuit> sigh
11:24 < phantomcircuit> btw maybe someone here knows of an easy way to do this
11:24 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Read error: Connection reset by peer]
11:24 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
11:24 < phantomcircuit> i've been trying to get the metadata for a torrent using just the info hash (ie through dht)
11:25 < phantomcircuit> but i cant find any simple tools to do this
11:25 < op_mul> I had one at some point
11:26 < op_mul> there's some command line tool that will get the metadata from a .torrent, or download it via DHT if you just give the hash. let me see if I can find it.
11:26 -!- askmike_ [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 265 seconds]
11:29 -!- Shiftos [~shiftos@gateway/tor-sasl/shiftos] has quit [Ping timeout: 250 seconds]
11:29 < op_mul> phantomcircuit: duno. the tool does exist though.
11:30 -!- Glyphnote_ [~Glyphnote@2600:1004:b013:9f11:60d0:515c:8a91:6231] has joined #bitcoin-wizards
11:31 -!- Shiftos [~shiftos@gateway/tor-sasl/shiftos] has joined #bitcoin-wizards
11:33 -!- epoche [~Glyphnote@2600:1004:b013:9f11:a46c:e148:441f:9ef9] has quit [Ping timeout: 244 seconds]
11:38 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Ping timeout: 240 seconds]
11:40 -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has quit [Quit: iang]
11:43 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards
11:51 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Remote host closed the connection]
12:06 -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards
12:07 -!- Dizzle [~Dizzle@2605:6000:1018:c0f5:c520:6d92:eed6:44a9] has joined #bitcoin-wizards
12:10 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards
12:11 -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Ping timeout: 250 seconds]
12:16 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
12:21 < adam3us> about the btcd guys I finally replied to them (this is on a flame-laden bitcointalk thread where one of them replied in defence of why its not a problem for them to be risking breaking consensus) to suggest they listen to https://archive.org/details/The_Science_of_Insecurity_
12:22 < adam3us> about why language security between different implementations is a critical aspect of host security problems.  (any encoding of messages is a language of some kind).  the talk is academic and specifically talks about the problem.
12:22 < adam3us> and invited them to talk about it (here or wherever) we'll see...
12:22 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Ping timeout: 245 seconds]
12:23 < pigeons> kind of reminds me of that android bug where the code to check the apk signature was in c and behaved differently than the java code in the installer
12:24 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards
12:24 < gwillen> pigeons: that was a wonderful bug, which I have personally exploited (it's pretty easy)
12:24 < adam3us> their specific example was hilarious, using this mode of thinking, they wer eable to find 10 different ways to fool a CA into signing a domain name that was displayed & interpreted differently to the CA than the browser
12:25 < adam3us> that was another research referred to briefly.  but the actual talk is quite interesting and focussed on fundamental limits of security particularly undecidability, halting problem related concept, and what that means specifically for the way secure code should be written, and what things you should avoid.
12:27 < pigeons> yeah CAs is a good one, anything with ASN.1
12:27 < adam3us> pigeons: at some point she says *cough*ASN.1*cough* as an example of something with undecidable parsing
12:33 < gwillen> adam3us: does she actually cough in the presentation? That's hilarious.
12:35 < adam3us> gwillen: yep its at 28c3 so she's playing to the audience a bit about p0wnage.
12:35 -!- vmatekol_ [~vmatekole@f055081095.adsl.alicedsl.de] has quit [Remote host closed the connection]
12:52 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Remote host closed the connection]
12:55 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection]
12:56 -!- hashtagg_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 240 seconds]
13:04 < tacotime> adam3us: i'm here and from conformal too
13:05 < adam3us> tacotime: you are? i thought u were talking about some other project a few days ago
13:05 < tacotime> i mean, the number of btcd nodes running on the network right now is pretty minimal if i recall
13:05 < tacotime> yeah, i'm doing some non-specifically btcd-related stuff
13:06 < adam3us> tacotime: well so the impression people had through the backchaneel is conformal was actively trying to persuade people to use btcd
13:06 < adam3us> tacotime: davec on bitcointalk didnt seem to view that as a fork risk.
13:07 < tacotime> and i'm not sure any mining nodes are running it, which i think could be a risk if there was a fork of some kind. my overall opinion is that reimplementation of bitcoin in other languages can only strengthen core, and that if you're running a node that's consensus specific you may want to run bitcoind along side it to make sure they're both stuck on the same fork.
13:08 < tacotime> conformal would like people to use btcd, because they've tried to program their own user-demanded use cases into it and have spent a lot of money on the project. so it's sort of reasonable.
13:09 < adam3us> tacotime: well whats not reasonable is breaking bitcoin consensus.
13:09 < wumpus> any plans for btcd to use libbitcoinconsensus?
13:09 < adam3us> tacotime: here's what davec said on bitcointalk
13:09 < tacotime> but i mean; that people are going to make daemons with other use cases is inevitable, e.g. coinbase which is on the ruby impl. that doesn't mean you shouldn't make sure your daemon isn't on the main fork.
13:10 -!- hashtagg_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards
13:10 -!- lclc_bnc is now known as lclc
13:10 < adam3us> tacotime: (about fork risk) this is a complete red herring and exists just as much with Bitcoin Core as it does with anything else.  The exact same thing can easily happen (and already has as you've noted) with Bitcoin Core. This is a real problem with the technology that needs to be solved independent of the number of implementations on the network.
13:10 < wumpus> making daemons with other use cases is fine, but ideally they'd use the samme consensus code
13:11 < adam3us> tacotime: (davec contd) In fact, working toward solutions which address this fundamental issue is necessary for Bitcoin Core too since it means mistakes there don't lead to undesirable consequences either.  The current approach is "well let's just hope it doesn't happen!" and frankly, that just isn't good enough.
13:11 < adam3us> tacotime: which is not what i wanted to here, as thats outright confused and incorrect
13:13 < adam3us> tacotime: "exists just as much with Bitcoin Core as it does with anything else." the point is we dont even care if its btcd consensus or bitcoin consensus (so long as btcd isnt horribly broken)… the point is making two consensus implementations compatible is *undecidable*
13:13 < adam3us> tacotime: ie actually mathematically hard, bordering on impossible.  and he needs to understand that.
13:15 -!- op_mul [~op_mul@178.62.78.122] has quit [Quit: Lost terminal]
13:18 < tacotime> well, yes, it's an impossibility. just as it's impossible to prove that bitcoind might not fork between versions or even the same versioned binary.
13:18 < adam3us> tacotime: anyway i wasnt trying to be hostile (to you nor davec) but encouraged him to listen to meredith patterson on language security as it applies to the fundamental limits of host security (lang sec as in parsing messages and equal processing when thats critical) https://archive.org/details/The_Science_of_Insecurity_
13:19 -!- Dizzle [~Dizzle@2605:6000:1018:c0f5:c520:6d92:eed6:44a9] has quit [Quit: Leaving...]
13:19 < tacotime> wumpus: not as of yet, we're retooling the consensus code but afaik we're on our own fork of that.
13:19 < adam3us> tacotime: ie listen to her because she knows what she's talking about and maybe there's some mistaken assumption that bitcoincore is trying to compete with btcd.
13:20 < wumpus> adam3us: it's fine to compete on everything else, but competing one the consensus code just doesn't make sense, we should aim to unify that between all node implementations
13:20 < tacotime> well, i think there'd just previously been a lot of cliquey-ness between conformal and the bitcoin core developers, and before we felt excluded from being considered part of core development. gmaxwell now hangs out on our servers and communicates with us on issues, which is good.
13:20 < adam3us> wumpus: exactly.
13:22 < adam3us> tacotime: a written and public confirmation that they would never encourage anyone to use btcd consensus critical code alone (without being overridden in case of dispute by libbitcoinconsensus) would go some way towards things.  cos thats kind of not what davec who says he's the team lead was saying on bitcointalk a day ago
13:22 < tacotime> how does libbitcoinconsensus handle reorgs? or is that considered an implementation specific thing?
13:22 < wumpus> tacotime: it doesn't go that deep yet
13:22 < wumpus> tacotime: as of 0.10 it just verifies transactions
13:23 < tacotime> I think it's a bad idea to handle that in the consensus lib
13:23 < tacotime> because there are a lot of ways to do that
13:23 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
13:23 < tacotime> I think single-chain verification would be ideal
13:23 < adam3us> tacotime: what i said to davec was if he was being constructive he could help work on libbitcoinconsensus for example
13:23 < tacotime> adam3us: well, one of the goals of btcd is a complete reimplementation entire in golang
13:24 < wumpus> tacotime: the idea is to support the API at multiple levels; so the lowest has been implemented now, verifying transactions
13:24 < adam3us> tacotime: its a very very very bad idea to reimplement the consensus part.
13:24 < tacotime> wumpus: ah, ok
13:24 < wumpus> tacotime: the highest level will likely include utxo management of some kind
13:24 < adam3us> tacotime: i suggest he listen to the meredith patterson presentatoin on langsec and then come talk about it.
13:24 < wumpus> tacotime:  handling reorganizations may be a step too far, although it needs to be roll-back-able
13:25 < tacotime> adam3us: well, we wanted partially for people to make their own alts with btcd, as experimental coins, though this hasn't really happened yet. in that use case it's not as big an issue.
13:25 -!- askmike_ [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
13:25 -!- laurentmt [~chatzilla@89-93-131-89.hfc.dyn.abo.bbox.fr] has joined #bitcoin-wizards
13:25 < adam3us> tacotime: you can go fork alts all you want as far as i'm concerned. tho there is money on some of them.  but if they're using btcd only, that seems fine.
13:25 < wumpus> tacotime: see https://github.com/bitcoin/bitcoin/blob/0.10/doc/release-notes.md#consensus-library
13:26 -!- askmike__ [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
13:27 < tacotime> adam3us: well i can talk to them about external syncing to bitcoind to ensure consensus. there's nothing in there for that yet i think, but it shouldn't be hard to program btcd to call bitcoind's api and make sure something hasn't gone pete tong.
13:27 < tacotime> wumpus: thx
13:27 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 256 seconds]
13:28 < tacotime> and i'll forward davec this conversation.
13:28 < adam3us> tacotime: i think its not safe to do otherwise.  personally i would think if they are actually going around persuading people to use btcd in isolation it would be justified to protect bitcoin users to issue a warning to bitcoin businesses and to the press.  its not a joking thing
13:29 -!- askmike_ [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 256 seconds]
13:29 < adam3us> tacotime: seems kind of a shitty thing to say, and i'm not being hostile to you (nor davec etc) but sometimes people just wont listen until they get bad press.  eg coinvalidation seemed that way.
13:30 -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has joined #bitcoin-wizards
13:31 -!- askmike__ [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 256 seconds]
13:32 < tacotime> adam3us: well, i mean, soon we're not even using leveldb anymore, so the risk of a fork may yet be real.
13:32 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: This computer has gone to sleep]
13:32 < adam3us> tacotime: you might want to look at what davec is saying on bitcointalk https://bitcointalk.org/index.php?topic=68655.msg9998327#msg9998327
13:33 < wumpus> the specific database used as backend is unlikely to create a fork, although as was shown with berkeleydb it's possible for bugs in the database to create behavior differences
13:33 -!- MoALTz_ [~no@user-46-112-49-198.play-internet.pl] has joined #bitcoin-wizards
13:34 < justanotheruser> "It has been publicly stated many, many times that it is being coded because the ecosystem severely needs multiple diverse implementations if Bitcoin is ever going to truly flourish to the level we all want it to. " -- do you need to reimplement consensus to have multiple implementations?
13:34 < wumpus> but most likely a fork would be caused by a subtle difference in transaction validation, script interpretation, etc, which is likely if you reimplement in a different language
13:35 -!- MoALTz [~no@user-46-112-49-198.play-internet.pl] has quit [Ping timeout: 255 seconds]
13:35 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
13:36 < wumpus> justanotheruser: consensus is just not something you can compete on, it's either the same or it's broken
13:37 < adam3us> wumpus: from the langsec presentation i'd imagine thats undecidable and hence extremely complex to avoid small differences. (and those even if tiny or boundary can of course be systematically abused to the detriment of whoever is on the wrong side of the fork)
13:38 < justanotheruser> wumpus: I agree for the most part. If we could somehow prove that one implementation would always evaluate the same as another and it was implementated more efficiently then that may be useful.
13:38 < wumpus> but re: leveldb, it is not a given that bitcoin core will keep using leveldb for all eternity either, though there are no plans to switch either, it works fine and isn't a bottleneck at the moment
13:38 < adam3us> i think the langsec talk is worth listening to, encourage people interested in this topic to watch, i found it altered my opinion for the worse about the hopes of making a compatible implementation when it really mattered.  https://archive.org/details/The_Science_of_Insecurity_
13:39 < wumpus> adam3us: agreed
13:39 < tacotime> i would agree that whatever is currently your mainchain needs to evaluate and validate the same across the entire network.
13:39 < wumpus> justanotheruser: you mean to be able to sync the chain faster? that's dominated by secp256k1 verifications anyhow
13:39 < tacotime> by whatever the dominant implementation is.
13:40 < justanotheruser> wumpus: I qualified it with it being more efficient because a less efficient implementation is bad for consensus in a different way
13:40 < kanzure> perhaps it would be useful to insist on byte-by-byte compatibility in the binary that runs consensus code (because otherwise everyone misinterprets it as a "control freak" thing)
13:40 < kanzure> s/everyone/gullible people
13:41 < tacotime> i'm not sure if there's debate at all as to whether that should be c++. there seems to be a lot of issues as to what language is good for writing blockchain consensus things.
13:41 < kanzure> s/compatibility/duplication
13:41 < wumpus> tacotime: there is no 'should be' debate, for better or worse the consensus code is specific c++
13:41 < tacotime> well, if you were to do it over, i mean.
13:42 < wumpus> tacotime: I'd rather have something else too, but the problem of potential incompatibility will exist in whatever language you decide to rewrite it in, that's the problem
13:42 < tacotime> satoshi made the choice for us w/r/t bitcoin.
13:42 < wumpus> tacotime: at least c++ is pretty low-level and can be bound to many other languages
13:42 < tacotime> wumpus: true
13:42 < wumpus> tacotime: would have been worse if it was, say, java
13:42 < tacotime> it's easy to hook into golang
13:43 < justanotheruser> I would bet that there are optimizations to the consensus code that can be done safely, but doing them safely would require a ton of research and auditing.
13:43 < tacotime> i would have reservations with satoshi if he had written it in java
13:43 < kanzure> right, mutual self-incompatibility is already a big enough problem, and then incompatibilities and differences between non-byte-exact implementations is an additional level of headache
13:43 < wumpus> justanotheruser: as I said above, the slowest part of validation is secp256k1, which is well defined
13:44 < justanotheruser> wumpus: are you saying that is a possible optimization?
13:44 < wumpus> justanotheruser: that's where optimization should be concentrated, not the tricky dangerous verification code
13:44 < justanotheruser> well that is part of the consensus code
13:45 < wumpus> justanotheruser: no argument there
13:46 < wumpus> kanzure: requiring it to be byte-exact the same may be a requirement too far, but I don't know
13:48 < kanzure> well, it needs to be something more specific for others to think about other than "they are not us" (i know that's not what you mean, but that's what it will be interpreted as)
13:48 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards
13:48 < tacotime> ehm, don't we already have that by the deterministic builds?
13:48 < wumpus> kanzure: I've done some experiments in compiling the consensus code to a neutral, well-defined bytecode architecture, e.g. Moxie, maybe that will make a good immutable definition at some point
13:49 < kanzure> wumpus: i think that squawking about that sort of plan and direction would be much more useful than the alternative things to say to the press
13:49 < kanzure> (i may be misinterpreting what has been proposed as the messaging, for which i apologize, but also i'll bbl)
13:49 < wumpus> kanzure: the rest of the devs don't really agree with me, but I'd be happy to see the consensus code in a separate well-guarded repository, so that it can be easier shared between node implementations, and it's easier to keep track of changes
13:49 < kanzure> no that's not the contentious issue there
13:50 -!- Dr-G [~Dr-G@gateway/tor-sasl/dr-g] has joined #bitcoin-wizards
13:51 < wumpus> kanzure: alternative things? I'm not talking about anything to the press
13:52 < kanzure> ah i'm confusing a separate conversation from yesterday, forgive me
13:52 < wumpus> kanzure: keeping this thing on the rails is enough work without making a media circus
13:52 < kanzure> yep understood
13:56 < justanotheruser> Is there some btcd thing in the news are something?
14:03 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
14:04 -!- Profreid [~Profreitt@gateway/vpn/privateinternetaccess/profreid] has quit [Quit: Profreid]
14:06 < adam3us> justanotheruser: no i said something offhand on another bitcointalk thread about btcd, and someone who it turns out is the btcd lead davc replied so we were discussing davec reply with tacotime who apparently works with btcd
14:06 < adam3us> justanotheruser: eg https://bitcointalk.org/index.php?topic=68655.msg9998327#msg9998327
14:16 -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has quit [Quit: iang]
14:23 -!- siervo [uid49244@gateway/web/irccloud.com/x-vemcsspcgbevmbpt] has joined #bitcoin-wizards
14:31 -!- op_mul [~op_mul@178.62.78.122] has joined #bitcoin-wizards
14:32 -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has joined #bitcoin-wizards
14:32 -!- catlasshrugged [~satoshi-u@63.142.161.3] has quit [Ping timeout: 244 seconds]
14:36 < justanotheruser> oh, thanks
14:37 < adam3us> justanotheruser: i guess if they inadvertenly forked bitcoin, that'd be negatively newsworthy :|
14:39 < justanotheruser> This is why there needs to be some Bitcoin best practices webpage that some of the core developers sign. For media purposes you can say "experts have agreed that doing this is a bad practice..."
14:40 < Taek> wumpus: I like the idea of setting a firm definition for consensus in something like moxie.
14:41 < adam3us> justanotheruser: i thought gmaxwell already spent a lot of time talkign with them, so they actually know.  maybe davec was just irritated by the offhand nature of my remark (in an unrelated thread) and so said some not so advisable things in response. but what he said doesnt sound on the face of it like he agrees even yet.
14:41 < adam3us> Taek: i agree.  moxie bytecode vm is a cool idea.  for that and some other things also.
14:42 < adam3us> Taek: (other things in bitcoin) eg it can enforce deterministic execution of extensions that are coded in its bytecode.
14:42 < justanotheruser> adam3us: yeah, but news media isn't going to cite obscure forum posts and obviously the btcd crew isn't going to change their mind
14:42 -!- catlasshrugged [~satoshi-u@208-58-112-15.c3-0.upd-ubr1.trpr-upd.pa.cable.rcn.com] has joined #bitcoin-wizards
14:43 < justanotheruser> even if davec backs down, reddit will probably have some quasi-activism to get btcd funded
14:44 < adam3us> justanotheruser: well i dont think it'd be wise to escalate it, but sure they would coindesk , even reddit noise, those rags are printign all kinds of alt-coin technobabble so they're obviously short of content
14:44 < adam3us> justanotheruser: cointelegraph, etc there's 1/2 a dozen of them.
14:45 < adam3us> justanotheruser: i think btcd is already funded, though its not public afaik (not that i tried to find out particularly hard short of asking davec - which he declined to answer)
14:46 < justanotheruser> I'm more concerned about forbes. If they could cite bitcoin.org/bestpractices as saying to not use a consensus reimplementation such as btcd, it is less negative
14:46 < justanotheruser> people would end up thinking "these people did something unsafe" rather than "bitcoin is unsafe"
14:46 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:118d:3cda:742b:32c7] has quit [Ping timeout: 265 seconds]
14:47 -!- siervo [uid49244@gateway/web/irccloud.com/x-vemcsspcgbevmbpt] has quit []
14:51 -!- laurentmt [~chatzilla@89-93-131-89.hfc.dyn.abo.bbox.fr] has quit [Quit: ChatZilla 0.9.91.1 [Firefox 34.0.5/20141126041045]]
14:51 < adam3us> justanotheruser: sounds like a good idea to me.
14:52 < adam3us> justanotheruser: could even cite the patterson presentation.  probably she has some journal publication on it also.
14:55 < op_mul> justanotheruser: btcd is almost certainly funded.
14:56 < op_mul> they wouldn't go to all that trouble for no reason
14:57 < adam3us> tacotime: said further up that they'd spent a lot of money building btcd (including some user requestsed features) so now they wanted to promote it to people which he thought was fair enough.  so that was the start of the discussion of well yes thats fair enough but please not the consensus part
14:57 < phantomcircuit> op_mul, im 90% sure someone working on it told me it was funded, but cant remember who...
14:57 < adam3us> justanotheruser: i meant.  just sentence started with tacotime.
14:58 < adam3us> phantomcircuit: its still a bit of a mystery about who or why.  seemingly to include user requested features into it and somehow monetize that i guess. but davec seem reluctant to say
14:58 < op_mul> it's an odd choice really.
14:59 < phantomcircuit> it wouldn't be unreasonable to build a server optimized for random access of various bits of the blockchain
14:59 < phantomcircuit> but i cant understand why you would bother with the consensus code
14:59  * op_mul rolls eyes
14:59 < op_mul> phantomcircuit: coinbase did it for you! 300GB of SQL, optimised everywhere. https://bitcoin.toshi.io/
14:59 < phantomcircuit> i got a nice laugh at the 300GB
15:00 < tacotime> good god
15:00 < phantomcircuit> they failed to take advantage of the indexing stuff postgresql can do
15:00 < phantomcircuit> like
15:00 < phantomcircuit> completely and entirely failed
15:00 < tacotime> btcd performs better than that heh. i think we have some of the lowest mem usage amongst implementations iirc
15:01 < phantomcircuit> it's really easy to setup the address stuff as character arrays with indexes that can run efficiently against them
15:01 < phantomcircuit> but instead they have a weird normalized/denormalized structure
15:01 < phantomcircuit> (i presume because doing this right is basically impossible using the rails orm)
15:01 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Remote host closed the connection]
15:02 < adam3us> here's what davec said about funding and why on https://bitcointalk.org/index.php?topic=68655.msg9998327#msg9998327
15:02 <@gmaxwell> op_mul: it's addressing a different application space; perhaps not a well advised one, but at least it's not using a ton of space because it straight up stupid.
15:02 < adam3us> phantomcircuit: "First, both of these are completely irrelevant.  No one knows who Satoshi was/is, yet that isn't a problem for Bitcoin Core.  So, even if every single contributor were unknown (they're not as you can find the names of every contributor on github), why would it be a problem for btcd when it isn't for Bitcoin Core?"
15:02 < phantomcircuit> lulz
15:03 < adam3us> phantomcircuit: oh the why was separate "It has been publicly stated many, many times that it is being coded because the ecosystem severely needs multiple diverse implementations if Bitcoin is ever going to truly flourish to the level we all want it to.  ...
15:03 < adam3us> phantomcircuit: … Thinking that a single implementation controlled by a handful of people is a good scheme for a system that is supposed to take over the World's monetary supply is just not very forward thinking.  This has been covered ad naseum."
15:04 < adam3us> phantomcircuit: the first comment was "a) no one knows who's funding them" and the second one was "c) no one knows why they are coding it;" so you can see those are pretty much NON answers.
15:04 -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has joined #bitcoin-wizards
15:04 < phantomcircuit> which kind of makes sense... but only from a very very high level and only if restricted to being used only be people willing to accept a huge risk to themselves and who are incapable of projecting that risk onto others (ie miners)
15:05 < adam3us> phantomcircuit: exactly.  my response was "about why consensus is hard, and more so for two different implementations, here are two presentations first on language security as it applies to host security and software compatibility and second on bitcoin consensus.  The first is quite eye opening even for security researchers (ie people who are experts in host security)."
15:05 < op_mul> gmaxwell: I don't really follow what, though. if it's meant to be the backend for services (for whatever reason they're not using a normal wallet), wouldn't just a handful of address based index make more sense?
15:05 < adam3us> phantomcircuit: language security https://archive.org/details/The_Science_of_Insecurity_
15:05 < adam3us> bitcoin consensus programming https://www.youtube.com/watch?v=on5ySFK0aoY#t=39m50s
15:06 < adam3us> phantomcircuit: "Have a listen, particularly to the first one and then we can discuss further (here or PM or bitcoin-dev or #bitcoin-wizards or whereever).  I am genuinely interested to help resolve the discrepancy of opinion around this, as its actually to my mind significantly misunderstood, and dangerous for bitcoin."
15:06 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards
15:06 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 240 seconds]
15:06 -!- JonTitor [~superobse@unaffiliated/superobserver] has quit [Ping timeout: 240 seconds]
15:06 < op_mul> gmaxwell: if you're trying to do stats or something with it, you can do it with no additional storage at all with a block chain scanner.
15:07 < adam3us> btw the second link if you rewind it is an hour of BlueMatt presenting on bitcoin in general.  at 39m50s he dives into "please dont reimplement consensus its a really, really bad idea" sub-topic
15:07 <@gmaxwell> op_mul: the problem arises when you won't or can't make a clean boundary about what data is presented, and so you may have to efficiently service ramdom access to anything; and there is no compact way to index that.
15:07 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-wizards
15:07 < BlueMatt> adam3us: that talk is wayyyy below people in this room, I think
15:07 -!- JonTitor [~superobse@unaffiliated/superobserver] has joined #bitcoin-wizards
15:08 < adam3us> BlueMatt: arf, i thought it was pretty good. btw did the pebble guy tell you anything afterwards? (guy who jumped in with obscure consensus algorithm comment at one point)
15:09 < adam3us> BlueMatt: (lurkers might find it educational anyway.)
15:10 -!- lclc is now known as lclc_bnc
15:14 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
15:16 -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has quit [Quit: iang]
15:17 -!- zer0veritas [zer0verita@c-67-185-255-98.hsd1.wa.comcast.net] has joined #bitcoin-wizards
15:17 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards
15:19 < midnightmagic> BlueMatt: your description of future-coding for internal redundancy in cooperative agents will benefit from the following result: 1. Blecher PM. On a logical problem. Discrete Mathematics. 1983;43(1):107-110. doi:10.1016/0012-365X(83)90026-2.
15:22 < midnightmagic> http://magicrulesunpaa6.onion/Blecher-1983-On_a_logical_problem.pdf for fulltext
15:25 < midnightmagic> Also note the massive cite tree hanging over that. The other (less pure IMO) results are a fascinating tree of similar results dating back to von Neumann: R. L. Dobrushin and S. I. Ortyukov, Lower bound for the redundancy of self-correcting arrangements of unreliable functional elements, Prob. Inf. Trans. 13 (1977), 59􏰈65.
15:28 < midnightmagic> and von Neumann's, for search a complete cite tree: J. von Neumann, Probabilistic logics and the synthesis of reliable organisms from unreliable components, in ``Automata Studies'' (C. E. Shannon and J. McCarthy, Eds.), pp. 329􏰈378, Princeton Univ. Press, Princeton, NJ, 1956.
15:28 -!- zer0veritas [zer0verita@c-67-185-255-98.hsd1.wa.comcast.net] has left #bitcoin-wizards []
15:31 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
15:31 < midnightmagic> And I can get all the fulltext of this various stuff if you find something and can't find the fulltext wherever.
15:33 < phantomcircuit> adam3us, in general i think having alternative implementations which nobody relies upon for correctness is a good thing, because if done correctly they find a bunch of bugs
15:33 < phantomcircuit> however i dont really see this happening
15:33 < phantomcircuit> mostly just because that's a lot of work with little to no reward
15:33 < adam3us> phantomcircuit: agree. they might find bugs in bitcoind for example.
15:35 -!- happycamper [~textual@104-96.105-92.cust.bluewin.ch] has joined #bitcoin-wizards
15:35 < midnightmagic> or they get too busy tracking down and eliminating bugs in their own code because they can't survive artificial memory pressures
15:35  * midnightmagic grumbles
15:36 -!- Glyphnote_ [~Glyphnote@2600:1004:b013:9f11:60d0:515c:8a91:6231] has quit [Quit: Leaving]
15:36 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards
15:45 -!- eudoxia [~eudoxia@r167-56-16-102.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving]
15:51 -!- Shiftos [~shiftos@gateway/tor-sasl/shiftos] has quit [Remote host closed the connection]
16:00 -!- Shiftos [~shiftos@gateway/tor-sasl/shiftos] has joined #bitcoin-wizards
16:01 -!- MoALTz [~no@user-46-112-49-198.play-internet.pl] has joined #bitcoin-wizards
16:03 -!- MoALTz_ [~no@user-46-112-49-198.play-internet.pl] has quit [Ping timeout: 244 seconds]
16:19 -!- happycamper [~textual@104-96.105-92.cust.bluewin.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
16:20 -!- MoALTz_ [~no@user-46-112-49-198.play-internet.pl] has joined #bitcoin-wizards
16:20 -!- zooko [~user@2601:1:8a82:7f00:71a3:e149:8329:9c23] has joined #bitcoin-wizards
16:22 -!- MoALTz [~no@user-46-112-49-198.play-internet.pl] has quit [Ping timeout: 244 seconds]
16:30 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Remote host closed the connection]
16:36 -!- MoALTz__ [~no@user-46-112-49-198.play-internet.pl] has joined #bitcoin-wizards
16:37 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:118d:3cda:742b:32c7] has joined #bitcoin-wizards
16:37 -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
16:38 -!- MoALTz_ [~no@user-46-112-49-198.play-internet.pl] has quit [Ping timeout: 245 seconds]
16:40 -!- MoALTz_ [~no@user-46-112-49-198.play-internet.pl] has joined #bitcoin-wizards
16:41 -!- MoALTz [~no@user-46-112-49-198.play-internet.pl] has joined #bitcoin-wizards
16:41 -!- catlasshrugged [~satoshi-u@208-58-112-15.c3-0.upd-ubr1.trpr-upd.pa.cable.rcn.com] has quit [Quit: Leaving]
16:42 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
16:43 -!- MoALTz__ [~no@user-46-112-49-198.play-internet.pl] has quit [Ping timeout: 265 seconds]
16:44 -!- MoALTz [~no@user-46-112-49-198.play-internet.pl] has quit [Max SendQ exceeded]
16:44 -!- MoALTz_ [~no@user-46-112-49-198.play-internet.pl] has quit [Ping timeout: 240 seconds]
16:45 -!- MoALTz [~no@user-46-112-49-198.play-internet.pl] has joined #bitcoin-wizards
16:48 -!- pgokeeffe [~pgokeeffe@101.165.93.194] has joined #bitcoin-wizards
16:49 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards
16:53 -!- pgokeeffe [~pgokeeffe@101.165.93.194] has quit [Ping timeout: 245 seconds]
16:55 -!- adam3us [~Adium@c31-67.i07-8.onvol.net] has quit [Quit: Leaving.]
16:55 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
17:00 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 256 seconds]
17:00 -!- zooko [~user@2601:1:8a82:7f00:71a3:e149:8329:9c23] has quit [Ping timeout: 244 seconds]
17:08 -!- CodeShark [~textual@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-wizards
17:09 < CodeShark> How do we design a decentralized consensus protocol that is generally extensible while minimizing the need for hardforks?
17:09 -!- jps [~Jud@23-122-17-11.lightspeed.brhmal.sbcglobal.net] has joined #bitcoin-wizards
17:10 < CodeShark> i.e. extensible headers and abstract data types seem like a good start
17:17 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Remote host closed the connection]
17:18 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-wizards
17:22 -!- tacotime [~mashkeys@198.52.200.63] has quit [Ping timeout: 255 seconds]
17:29 < justanotheruser> CodeShark: maybe we could allow people to transfer wealth between different blockchains with different rules where the blockchains aren't in consensus with each other, but there is consensus within each individual blockchain
17:29 < justanotheruser> I think thats actually being implemented
17:30 -!- hashtagg_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 240 seconds]
17:30 < justanotheruser> We can't allow people to vote on the rules or you have NaS problems. We could allow miners to decide the rules, but everyone would have SPV security. What you are left with is what I just mentioned
17:30 -!- hashtagg_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards
17:36 < CodeShark> sidechains can help bootstrap the development...but I think my question is less about the decision process in adding improvements - more about how to design the protocol such that deploying such improvements amounts to just flipping a switch
17:40 < CodeShark> well, I guess there are two issues here - one is how the implementation itself is distributed...the other is how we switch over to it with as little disruption to the existing network as possible
17:41 < kanzure> you mean each user/operator flips the switch, or who flips?
17:41 < CodeShark> that's still an open issue - assuming we had a solution to this issue
17:42 < justanotheruser> CodeShark: who decides what new consensus rules are valid?
17:42 -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards
17:42 < justanotheruser> the miners? the stake holders? A not-sybil-resistant majority of nodes? A central authority?
17:42 < CodeShark> well, right now it's the core developers, I suppose
17:42 < CodeShark> but setting that issue aside
17:42 < justanotheruser> no, the miners decide softforks
17:43 < justanotheruser> there have been no hardforks
17:43 < CodeShark> the miners decide on softforks that are proposed by the core developers
17:43 < justanotheruser> or they could decide on softforks proposed by a homeless guy
17:44 < rusty> justanotheruser: yes, there was, and the miners resolved that too.  In the end, you need miner consensus, but you also need user consensus if your bitcoins are to be worth anything.
17:44 < CodeShark> but for the sake of discussion, imagine we had a procedure in place for reaching consensus on new protocol rules
17:44 < CodeShark> my question is more about the mechanism for its deployment
17:44 < justanotheruser> rusty: what hardfork
17:44 < CodeShark> everyone agreed "yes, I love feature X - let's add it"
17:44 < rusty> justanotheruser: the large block hardfork.  https://bitcoin.org/en/alert/2013-03-11-chain-fork
17:44 < CodeShark> we have an implementation for it and it's been tested
17:45 < CodeShark> now how do we deploy?
17:45 < justanotheruser> rusty: that wasn't a hardfork to my understanding
17:45 < CodeShark> actually, miners didn't resolve that one - and it was a hardfork due to a bug
17:46 < justanotheruser> CodeShark: see above
17:46 < rusty> justanotheruser: not a deliberate one, no... and CodeShark, they certainly did, by downgrading.
17:46 < CodeShark> miners did so by STRONG encouragement from the core devs
17:46 < justanotheruser> afaik, that was more of a softfork if you can call it that
17:46 < CodeShark> many miners would have liked to just stay on the nonbuggy chain
17:47 < CodeShark> the majority of hashing power was on the nonbuggy chain
17:47 < rusty> CodeShark: in pettycoin, I had a features field in the tx and the block.  Default implementation of miner set the features field corresponding to the majority of txs in the block.  If a feature got a supermajority in a fortnight block, the version number was bumped 4 weeks  later (ie. you got warning that a change was coming).
17:48 < justanotheruser> the problem was that 0.7 broke consensus with itself. There was a database bug that meant that it wasn't deterministically in consensus with itself.
17:48 < justanotheruser> 0.3 still can still achieve consensus with 0.9.3
17:49 < rusty> justanotheruser: new clients accept and old clients don't == hardfork.  I don't know what else to call it.
17:49 < CodeShark> or at least the rules were not really known, even if deterministic
17:49 < CodeShark> if everyone implements the same bug which changes consensus rules, the implemented rules become the *real* rules
17:49 < justanotheruser> rusty: some 0.7 clients still worked
17:50 < justanotheruser> rusty: 0.7 broke consensus with itself.
17:51 < CodeShark> anyhow, there hasn't really been a deliberate hardfork, has there?
17:51 < justanotheruser> no
17:52 < rusty> justanotheruser: true, you could configure it to break consensus, but that's hardly relevant.  Your question requires analysis of the various players, and we have one real data point.  Insisting any one of users/miners/devs has/hasn't power is an oversimplification.
17:53 < justanotheruser> here is discussion on what 0.7-0.8 was (it's pretty short) http://hastebin.com/ofuqizomuw.xml
17:54 < e1782d11df4c9914> that langsec video was very enlightening, to whomever had posted it up above
17:54 < justanotheruser> 0.8 was a non-deterministic-hardfork-softfork-non-deterministic-hardfork-deterministic-softfork-fork
17:55 < CodeShark> hah
17:55 < rusty> CodeShark: See the P2SH deployment BIP (16).  That method is probably the one which would be used in future, given it worked.
17:56 < justanotheruser> p2sh deployment was a softfork and no one broke consensus...
17:56 < justanotheruser> it's completely different. You just need a majority of miners to upgrade and no one gets hurt. In a hardfork *everyone* needs to upgrade.
17:58 < justanotheruser> If a hardfork is completely necessary, you should make it so it is active in the amount of time that hurts the collective users the least. The way you can hurt the users is A) through the entire userbase not upgrading in time and suffering the consequences the hardfork was trying to prevent or B) users not upgrading fast enough and breaking consensus
17:58 < justanotheruser> really, what do you need a hardfork for though?
17:59 < rusty> justanotheruser: >1MB blocks will be a hardfork, AFAICT.
17:59 < rusty> justanotheruser: weakening SHA256 would be another, but that's more speculative.
17:59 < justanotheruser> rusty: I don't think a blocksize increase will happen, but I could be wrong
18:00 < justanotheruser> Increasing the blocksize only solves the problem until the transaction volume matches up with the blocksize once again
18:01 < justanotheruser> and its a controversial hardfork.
18:02 < rusty> justanotheruser: I disagree; I think it will happen.  I think the controversy means it will be done in some minimal way (eg. ceiling increased at some set rate) with no other changes despite the temptation to break everything at once.
18:03 <@gmaxwell> CodeShark: I think your mental model for how things work is at best outdated. We (bitcoin core people) no longer even have contact information for anywhere near a majority of the hashrate anymore.
18:04 < CodeShark> gmaxwell: I remember there having been first consensus amonst the core devs to downgrade during that incident...then a big effort to get all the big mining pools to downgrade
18:04 < CodeShark> not saying such an approach is still doable, let alone desirable
18:04 <@gmaxwell> rusty: 0.7 was inconsistent with _itself_.  Many (most?) 0.7 nodes happily also accepted the new chain, I haven't checked recently but I wouldn't be surprised if unmodified pre 0.8 would sync up the current chain now, it did for a long time into 0.8, only to sometimes fail on reorg depending on the particulars of the nodes past state.
18:05 < moa> if transactions rates die the ceiling will not need to be lifted arbitrarily
18:05 < CodeShark> gmaxwell: I also remember there being an offer extended to the mining pools who lost bitcoins to compensate them from Bitcoin Foundation funds
18:05 <@gmaxwell> CodeShark: go look at the log :) , downgrading was proposed by one of the large mining pools (luke), on the basis of it being compatible with more of the running hosts e.g. the path that was not a hard fork.
18:06 < CodeShark> luke is more of a core dev than a large mining pool :P
18:06 <@gmaxwell> At the time we didn't know the split was non-determinstic and mistook it for a plain hardfork.
18:08 <@gmaxwell> CodeShark: and there wasn't a "big effort" slush (who'd triggered the event and elu. were already in the room; and with luke they were a supermajority of the hashrate.) The whole thing was partially as much of a shitshow as it was because miners were running software that was inconsistent with the vast majority of the network (as they updated quickly).
18:09 < CodeShark> gmaxwell: details aside, I think it's a scenario that most of us would like to generally avoid
18:09 <@gmaxwell> justanotheruser: BIP16's deployment was minorly consensus breaking. A better example would be BIP34.
18:09 < rusty> gmaxwell: Ah, thanks for the clarification.  I only read the alert and the summary, which imply it's all 0.7 vs all 0.8.
18:10 <@gmaxwell> justanotheruser: there were some number of orphan blocks because the transactions BIP16 made invalid were IsStandard.
18:10 < moa> it was actually a good example of how the miners will not hardfork onto a minority branch
18:11 <@gmaxwell> rusty: the summary was written before it was really completely misunderstood. Oh well. It's so widely misunderstood now that I'm sure that'll become the "truth" in the history books.
18:11 <@gmaxwell> moa: I agree.
18:11 < moa> at least the ones that were awake
18:11 < rusty> gmaxwell, moa: yeah, if bitcoin fails we don't need to worry about hardforks? :)
18:12 < rusty> (Oh, I was responding to moa's previous comment re: tx rates dying)
18:12 <@gmaxwell> rusty: Basically implicit BDB behavior would make it take upto 2x the number of locks depending on the layout of the records on disk, which was not a pure function of the blockchain-- depended on things like startup/shutdown history and reorgs.
18:13 <@gmaxwell> rusty: 0.7 could happily have had this fault all on its own even if 0.8 was never released. (the triggering event wasn't 0.8 either, it was slush upping his maximum block size after being bugged by someone)
18:14 <@gmaxwell> ( https://bitcointalk.org/index.php?topic=149668.0 )
18:17 <@gmaxwell> CodeShark: I think whas justanotheruser was saying was basically that if sidechains are successful they remove that issue. You make your changes to a sidechain and then move things onto it, so there is no flag day; not in terms of decision or approval, and not in terms of a technical software transistion.
18:28 -!- Nightwolf [~Nightwolf@unaffiliated/nightwolf] has quit [Read error: Connection reset by peer]
18:30 -!- Dr-G2 [~Dr-G@gateway/tor-sasl/dr-g] has joined #bitcoin-wizards
18:30 < CodeShark> gmaxwell: what about the security model?
18:31 < CodeShark> gmaxwell: I suppose you'd also need to get miners to switch over to the new chain
18:33 -!- Dr-G [~Dr-G@gateway/tor-sasl/dr-g] has quit [Ping timeout: 250 seconds]
18:33 < BlueMatt> ;;later tell adam3us yes, the pebble guy and I had a marginally useful discussion afterwards
18:34 < BlueMatt> nanotube: wtf, where's gribble?
18:34 < BlueMatt> didnt it used to be here
18:34 < BlueMatt> ?
18:35 <@gmaxwell> no.
18:35 < CodeShark> gmaxwell: how's OP_SIDECHAINPROOFVERIFY coming along?
18:35 < BlueMatt> D=
18:38 -!- jps [~Jud@23-122-17-11.lightspeed.brhmal.sbcglobal.net] has quit [Quit: jps]
18:49 -!- catlasshrugged [~satoshi-u@208-58-112-15.c3-0.upd-ubr1.trpr-upd.pa.cable.rcn.com] has joined #bitcoin-wizards
18:49 -!- catlasshrugged [~satoshi-u@208-58-112-15.c3-0.upd-ubr1.trpr-upd.pa.cable.rcn.com] has quit [Client Quit]
18:49 -!- catlasshrugged [~satoshi-u@208-58-112-15.c3-0.upd-ubr1.trpr-upd.pa.cable.rcn.com] has joined #bitcoin-wizards
18:53 -!- wyager [~wyager@cpe-24-160-153-232.satx.res.rr.com] has joined #bitcoin-wizards
18:54 -!- Dizzle [~Dizzle@cpe-72-182-36-12.austin.res.rr.com] has joined #bitcoin-wizards
19:06 -!- coiner [~linker@42.116.152.78] has joined #bitcoin-wizards
19:17 < CodeShark> I take my earlier comment regarding switching miners to the new chain back - obviously the way to do it would be to merge mine the two
19:18 < CodeShark> (assuming the consensus model is essentially unchanged)
19:27 -!- wyager [~wyager@cpe-24-160-153-232.satx.res.rr.com] has quit [Quit: wyager]
19:28 -!- Starduster_ [~guest@unaffiliated/starduster] has joined #bitcoin-wizards
19:28 -!- hashtagg [~hashtagg_@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards
19:29 -!- spinza [~spin@197.89.19.57] has quit [Ping timeout: 240 seconds]
19:29 -!- spinza [~spin@197.89.19.57] has joined #bitcoin-wizards
19:29 -!- spinza [~spin@197.89.19.57] has quit [Excess Flood]
19:30 -!- spinza [~spin@197.89.19.57] has joined #bitcoin-wizards
19:30 -!- spinza [~spin@197.89.19.57] has quit [Excess Flood]
19:30 -!- hashtag [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards
19:31 -!- hashtagg_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 240 seconds]
19:31 -!- hashtag_ [~hashtagg_@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 240 seconds]
19:31 -!- Starduster [~guest@unaffiliated/starduster] has quit [Ping timeout: 240 seconds]
19:31 -!- spinza [~spin@197.89.19.57] has joined #bitcoin-wizards
19:31 -!- jps [~Jud@23-122-17-11.lightspeed.brhmal.sbcglobal.net] has joined #bitcoin-wizards
19:33 < phantomcircuit> gmaxwell, so question, a pow function that does have forward progress should be fairly trivial right? just feed a hash function back into itself x times
19:34 < phantomcircuit> hmm yeah that would be entirely trivial
19:37 -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has joined #bitcoin-wizards
19:46 -!- user7779078 [user777907@gateway/vpn/mullvad/x-cyvyoejhorzmrxib] has quit [Remote host closed the connection]
19:47 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards
19:49 -!- wyager [~wyager@cpe-24-160-153-232.satx.res.rr.com] has joined #bitcoin-wizards
19:50 -!- wyager [~wyager@cpe-24-160-153-232.satx.res.rr.com] has quit [Client Quit]
19:52 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has quit [Ping timeout: 240 seconds]
19:58 < tromp> phantomcircuit: the original Momentum proposal (find a hash collision between any two nonces) is progress-full
19:59 < tromp> (the hash output was limited to 50 bits)
19:59 < phantomcircuit> for anybody wondering this is not really for a pow
20:04 -!- coiner [~linker@42.116.152.78] has quit [Ping timeout: 264 seconds]
20:18 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 265 seconds]
20:19 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards
20:22 -!- Dyaheon- [~dya@83-25-196-88.dyn.estpak.ee] has joined #bitcoin-wizards
20:22 -!- guest7399 [~guest@5ED11658.cm-7-2a.dynamic.ziggo.nl] has joined #bitcoin-wizards
20:23 -!- Dyaheon [~dya@83-25-196-88.dyn.estpak.ee] has quit [Ping timeout: 240 seconds]
20:23 -!- tacotime [~mashkeys@198.52.200.63] has joined #bitcoin-wizards
20:25 -!- Starduster_ [~guest@unaffiliated/starduster] has quit [Ping timeout: 240 seconds]
20:35 -!- adam3us [~Adium@c31-67.i07-8.onvol.net] has joined #bitcoin-wizards
20:38 -!- wserd [5fd38811@gateway/web/cgi-irc/kiwiirc.com/ip.95.211.136.17] has joined #bitcoin-wizards
20:56 -!- guest7399 [~guest@5ED11658.cm-7-2a.dynamic.ziggo.nl] has quit [Ping timeout: 240 seconds]
21:15 -!- adam3us [~Adium@c31-67.i07-8.onvol.net] has quit [Quit: Leaving.]
21:17 -!- coiner [~linker@115.79.55.177] has joined #bitcoin-wizards
21:19 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-wizards
21:35 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards
21:41 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has quit [Ping timeout: 250 seconds]
21:43 < rusty> Is there a variant of atomic swaps which can tolerate tx malleability?
21:44 < rusty> (Or am I misunderstanding the proposal in Appendix C of the sidechains paper, which seems subject to refund breakage via txmal).
21:45 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards
21:45 -!- jps [~Jud@23-122-17-11.lightspeed.brhmal.sbcglobal.net] has quit [Quit: jps]
21:48 <@gmaxwell> rusty: malleability will be at the senders option in bitcoin in a couple months-ish.
21:49 -!- user7779_ [user777907@gateway/vpn/mullvad/x-aldplgulhmkezhlt] has joined #bitcoin-wizards
21:49 <@gmaxwell> There are two things ongoing which both seperately address this (BIP62 and BIP65).
21:50 -!- Dizzle [~Dizzle@cpe-72-182-36-12.austin.res.rr.com] has quit [Quit: Leaving...]
21:50 < rusty> gmaxwell: right, so we're assuming that's solved.  Fair enough, but a footnote in the sidechains paper would have been nice.    I found the https://en.bitcoin.it/wiki/Atomic_cross-chain_trading which doesn't  mention this caveat either.
21:50 -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has quit [Ping timeout: 244 seconds]
21:52 <@gmaxwell> rusty: pretty sure we actually mention it in there at some point and cite bip62.
21:52 < rusty> gmaxwell: hmm... CHECKLOCKTIMEVERIFY does avoid the refund TX nicely and simplifies the protocol.
21:55 <@gmaxwell> rusty: there are other dodges, at the expense of complexity. There is a BCT post from me where I describe how to partially blind the refund which makes it so an attacker has to go after _all_ transactions rather than just one.  But it's enough extra to worry about that I don't normally mention it. (but you asked for variants) https://bitcointalk.org/index.php?topic=303088.0
21:55 < rusty> gmaxwell: not in appendix C. The only reference I can find is in 5.1.1 talking about things that could  be done in sidechain experiments.
21:57 <@gmaxwell> rusty: ah, darn, well thats an error of the sort that creeps in from a "did we remember to point out {foo}" spotchecks. :-/
21:57 <@gmaxwell> I think also at the time that text was written we expected the paper to be published later relative to BIP62.
21:58 < rusty> gmaxwell: thanks for the confirmation, at least I'll mention in my 1-page description of atomic swaps.
22:15 -!- op_mul [~op_mul@178.62.78.122] has quit [Quit: Lost terminal]
22:15 -!- zooko` [~user@c-75-70-204-109.hsd1.co.comcast.net] has joined #bitcoin-wizards
22:16 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: This computer has gone to sleep]
22:17 -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has quit [Ping timeout: 245 seconds]
22:50 -!- gavink [uid60113@gateway/web/irccloud.com/x-zesecevohuyezuol] has joined #bitcoin-wizards
22:53 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 265 seconds]
22:56 -!- user7779_ [user777907@gateway/vpn/mullvad/x-aldplgulhmkezhlt] has quit [Remote host closed the connection]
22:59 -!- Profreid [~Profreitt@gateway/vpn/privateinternetaccess/profreid] has joined #bitcoin-wizards
23:15 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:118d:3cda:742b:32c7] has quit [Ping timeout: 244 seconds]
23:16 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards
23:18 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-wizards
23:20 -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 244 seconds]
23:25 -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards
23:35 -!- fanquake [~anonymous@unaffiliated/fanquake] has joined #bitcoin-wizards
23:44 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
23:57 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:118d:3cda:742b:32c7] has joined #bitcoin-wizards
--- Log closed Mon Jan 05 00:00:13 2015