| --- Log opened Sun Jan 04 00:00:13 2015 | ||
| -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards | 00:11 | |
| -!- lclc_bnc is now known as lclc | 00:14 | |
| -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 244 seconds] | 00:15 | |
| -!- lclc is now known as lclc_bnc | 00:17 | |
| -!- lclc_bnc is now known as lclc | 00:18 | |
| -!- adam3us [~Adium@c31-67.i07-8.onvol.net] has joined #bitcoin-wizards | 00:32 | |
| -!- cluckj [~cluckj@cpe-24-92-48-18.nycap.res.rr.com] has quit [Ping timeout: 255 seconds] | 00:38 | |
| -!- kristofferR [~kristoffe@208.37-191-147.fiber.lynet.no] has joined #bitcoin-wizards | 00:40 | |
| -!- vmatekole [~vmatekole@g227232254.adsl.alicedsl.de] has joined #bitcoin-wizards | 00:52 | |
| -!- bosma_ [~bosma@S01067cb21bda6531.vc.shawcable.net] has joined #bitcoin-wizards | 00:57 | |
| -!- 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.] | 00:59 | |
| -!- bosma [~bosma@S01067cb21bda6531.vc.shawcable.net] has quit [Ping timeout: 240 seconds] | 01:00 | |
| -!- adam3us [~Adium@c31-67.i07-8.onvol.net] has joined #bitcoin-wizards | 01:02 | |
| -!- andy-logbot [~bitcoin--@wpsoftware.net] has quit [Remote host closed the connection] | 01:05 | |
| -!- andy-logbot [~bitcoin--@wpsoftware.net] has joined #bitcoin-wizards | 01:05 | |
| * andy-logbot is logging | 01:05 | |
| -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards | 01:11 | |
| -!- 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:15 | |
| -!- bosma is now known as Guest40810 | 01:16 | |
| -!- NewLiberty [~NewLibert@2602:304:cff8:1580:118d:3cda:742b:32c7] has quit [Ping timeout: 244 seconds] | 01:35 | |
| 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:42 |
|---|---|---|
| -!- Guest40810 is now known as bosma | 01:43 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards | 01:48 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Client Quit] | 01:52 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards | 01:56 | |
| -!- fanquake [~anonymous@unaffiliated/fanquake] has joined #bitcoin-wizards | 01:56 | |
| -!- 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:11 | |
| -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 245 seconds] | 02:15 | |
| -!- MoALTz_ [~no@user-46-112-49-198.play-internet.pl] has quit [Quit: going back to sleep] | 02:21 | |
| -!- kristofferR [~kristoffe@208.37-191-147.fiber.lynet.no] has quit [Quit: Textual IRC Client: www.textualapp.com] | 02:24 | |
| -!- moa [~kiwigb@opentransactions/dev/moa] has quit [Quit: Leaving.] | 02:32 | |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards | 02:34 | |
| -!- vmatekole [~vmatekole@g227232254.adsl.alicedsl.de] has quit [Remote host closed the connection] | 02:42 | |
| -!- MoALTz [~no@user-46-112-49-198.play-internet.pl] has joined #bitcoin-wizards | 03:00 | |
| -!- NewLiberty [~NewLibert@2602:304:cff8:1580:118d:3cda:742b:32c7] has joined #bitcoin-wizards | 03:08 | |
| -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has joined #bitcoin-wizards | 03:10 | |
| -!- 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:11 | |
| -!- e1782d11df4c9914 [~e1782d11d@cpe-66-68-54-206.austin.res.rr.com] has quit [Ping timeout: 244 seconds] | 03:14 | |
| -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 245 seconds] | 03:16 | |
| -!- Profreid [~Profreitt@gateway/vpn/privateinternetaccess/profreid] has joined #bitcoin-wizards | 03:18 | |
| -!- 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:19 | |
| -!- e1782d11df4c9914 [e1782d11df@gateway/vpn/mullvad/x-qbelspgnotskqrfz] has joined #bitcoin-wizards | 03:20 | |
| -!- Pan0ram1x [~Pan0ram1x@095-096-084-122.static.chello.nl] has joined #bitcoin-wizards | 03:25 | |
| -!- Pan0ram1x is now known as Guest52336 | 03:25 | |
| -!- e1782d11df4c9914 [e1782d11df@gateway/vpn/mullvad/x-qbelspgnotskqrfz] has quit [Ping timeout: 240 seconds] | 03:28 | |
| -!- e1782d11df4c9914 [e1782d11df@gateway/vpn/mullvad/x-eubqdwlmaglraihu] has joined #bitcoin-wizards | 03:30 | |
| -!- lclc [~lclc@bothniafur.com] has quit [Changing host] | 03:33 | |
| -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-wizards | 03:33 | |
| -!- d1ggy [~d1ggy@dslb-088-073-178-227.088.073.pools.vodafone-ip.de] has joined #bitcoin-wizards | 03:48 | |
| -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards | 04:11 | |
| -!- cluckj [~cluckj@cpe-24-92-48-18.nycap.res.rr.com] has joined #bitcoin-wizards | 04:12 | |
| -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 240 seconds] | 04:15 | |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Remote host closed the connection] | 04:18 | |
| -!- Aquent [~Aquent@gateway/tor-sasl/aquent] has quit [Ping timeout: 250 seconds] | 04:31 | |
| -!- 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:37 | |
| -!- spinza [~spin@197.89.19.57] has joined #bitcoin-wizards | 04:38 | |
| -!- NewLiberty [~NewLibert@2602:304:cff8:1580:118d:3cda:742b:32c7] has quit [Ping timeout: 244 seconds] | 04:49 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards | 04:52 | |
| -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has quit [Quit: iang] | 04:58 | |
| -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has joined #bitcoin-wizards | 05:00 | |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards | 05:07 | |
| -!- hashtagg [~hashtagg_@69.23.213.3] has quit [Ping timeout: 255 seconds] | 05:08 | |
| -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards | 05:11 | |
| -!- spinza [~spin@197.89.19.57] has quit [Ping timeout: 240 seconds] | 05:13 | |
| -!- spinza [~spin@197.89.19.57] has joined #bitcoin-wizards | 05:14 | |
| -!- spinza [~spin@197.89.19.57] has quit [Excess Flood] | 05:14 | |
| -!- 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:15 | |
| -!- 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: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 quit [Read error: Connection reset by peer] | 05:19 | |
| -!- hashtag_ [~hashtagg_@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 240 seconds] | 05:21 | |
| -!- askmike_ [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 240 seconds] | 05:23 | |
| -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards | 05:24 | |
| -!- 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:26 | |
| -!- hashtag_ [~hashtagg_@CPE-69-23-213-3.wi.res.rr.com] has joined #bitcoin-wizards | 05:29 | |
| -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 240 seconds] | 05:30 | |
| -!- 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:33 | |
| e1782d11df4c9914 | any serious implementations of MPC with respect to coinjoin anyone know of as being in development atm? | 05:38 |
| op_mul | MPC? | 05:46 |
| op_mul | oh right. | 05:47 |
| -!- d1ggy [~d1ggy@dslb-088-073-178-227.088.073.pools.vodafone-ip.de] has quit [Quit: Leaving] | 05:48 | |
| 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:49 |
| 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:50 |
| 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:51 |
| -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards | 05:53 | |
| op_mul | I can't speak for what anybody else is doing. | 05:55 |
| 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:56 |
| 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. | 05:59 |
| 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:05 |
| -!- askmike_ [~askmike@94.100.16.225] has joined #bitcoin-wizards | 06:06 | |
| 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:07 | |
| 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:08 |
| 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:09 |
| 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:10 | |
| -!- 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:11 | |
| -!- askmike_ [~askmike@94.100.22.70] has quit [Ping timeout: 250 seconds] | 06:14 | |
| -!- zooko`` [~user@c-75-70-204-109.hsd1.co.comcast.net] has joined #bitcoin-wizards | 06:22 | |
| -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has joined #bitcoin-wizards | 06:24 | |
| -!- 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:28 | |
| -!- zooko`` is now known as zooko | 06:31 | |
| -!- coiner [~linker@42.116.152.78] has joined #bitcoin-wizards | 06:32 | |
| -!- 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:39 | |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Remote host closed the connection] | 06:45 | |
| -!- NewLiberty_ [~NewLibert@2602:304:cff8:1580:118d:3cda:742b:32c7] has left #bitcoin-wizards ["Leaving"] | 06:47 | |
| -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has quit [Quit: iang] | 07:00 | |
| -!- hearn [~mike@84-75-198-85.dclient.hispeed.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 07:31 | |
| -!- 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:21 | |
| -!- 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:24 | |
| 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:27 |
| -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has joined #bitcoin-wizards | 08:29 | |
| -!- fanquake [~anonymous@unaffiliated/fanquake] has left #bitcoin-wizards [] | 08:34 | |
| sipa | ask gmaxwell | 08:38 |
| Taek | relevant: http://garzikrants.blogspot.com/2013/01/storj-and-bitcoin-autonomous-agents.html | 08:40 |
| jgarzik | ^ | 08:42 |
| Taek | seems like the original idea was not decentralized? | 08:43 |
| 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:44 |
| -!- a5m0 [~a5m0@unaffiliated/a5m0] has quit [Quit: No Ping reply in 180 seconds.] | 08:46 | |
| -!- a5m0 [~a5m0@unaffiliated/a5m0] has joined #bitcoin-wizards | 08:47 | |
| jgarzik | Taek, the original idea has nothing to do with altcoins | 08:48 |
| 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:49 |
| Taek | I don't claim to know very much about stroj the altcoin, I've never properly groked their whitepapers | 08:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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? :) | 08:59 |
| 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:00 |
| -!- 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:07 |
| 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:08 |
| 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:09 |
| @gmaxwell | kanzure: I mean you can't make it secret from the party recieving the request. | 09:10 |
| 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:11 |
| 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:12 |
| kanzure | http://diyhpl.us/~bryan/papers2/bitcoin/Deleting%20secret%20data%20with%20public%20verifiability.pdf | 09:13 |
| 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:14 |
| @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:15 |
| -!- lclc is now known as lclc_bnc | 09:17 | |
| @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:18 | |
| @gmaxwell | should be called "promise of deletion" not "proof of deletion" :P | 09:19 |
| -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-wizards | 09:21 | |
| 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:22 |
| 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:23 |
| @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:25 |
| 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:26 |
| -!- 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:28 |
| adam3us | gmaxwell: but then he's back to having to be around to repair his own files. | 09:29 |
| -!- vmatekol_ [~vmatekole@f055081095.adsl.alicedsl.de] has joined #bitcoin-wizards | 09:35 | |
| 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:36 |
| 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:37 | |
| -!- vmatekole [~vmatekole@g227232254.adsl.alicedsl.de] has quit [Ping timeout: 255 seconds] | 09:38 | |
| adam3us | gmaxwell: yeah that was a little circular. | 09:38 |
| 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:39 |
| adam3us | Taek: yeah what gmaxwell was saying up a bit was it'd all end up on one disk. | 09:40 |
| -!- 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:42 |
| 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:50 |
| op_mul | I don't see why not. | 09:51 |
| 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:52 |
| 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 | 09:54 |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards | 10:03 | |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Remote host closed the connection] | 10:05 | |
| -!- jtimon [~quassel@34.pool85-59-141.dynamic.orange.es] has quit [Ping timeout: 250 seconds] | 10:11 | |
| Taek | adam3us: m2m? | 10:15 |
| -!- jtimon [~quassel@16.pool85-53-130.dynamic.orange.es] has joined #bitcoin-wizards | 10:18 | |
| -!- eudoxia [~eudoxia@r167-56-16-102.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards | 10:20 | |
| op_mul | adam3us: even if it worked I question the utility of such a service. | 10:24 |
| -!- coiner [~linker@42.116.152.78] has quit [Ping timeout: 250 seconds] | 10:25 | |
| 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:26 |
| 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:27 | |
| 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:28 | |
| op_mul | if you encrypt your backups, it doesn't matter where they are stored so long as they exist in some form. | 10:29 |
| 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:30 |
| 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:32 |
| op_mul | adam3us: there's no reason to make things decentralised unless they absolutely need to be. the inefficiencies make it quite undesirable. | 10:34 |
| 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:36 |
| op_mul | I don't really follow there. | 10:37 |
| Taek | In a system of p2p storage, you have hundreds to thousands of nodes distributed all over the world | 10:38 |
| 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:39 |
| 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:40 |
| Taek | and you get much stronger geographic redundancy | 10:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| -!- 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:45 |
| 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:46 |
| @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:47 |
| @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:48 |
| 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:49 |
| 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:51 | |
| 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:52 |
| 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:53 |
| -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards | 10:54 | |
| @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:55 |
| -!- 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:56 | |
| @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:57 |
| op_mul | https://www.youtube.com/watch?v=eSMeUPFjQHc < every time you say erasure coding. | 10:58 |
| @gmaxwell | I have a couple erasure albums around here someplace. | 10:59 |
| 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:00 |
| sipa | zooko: reading backlogs and chatting while having a date is totally in | 11:01 |
| zooko | Haha | 11:01 |
| 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:02 |
| 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:04 | |
| -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has joined #bitcoin-wizards | 11:17 | |
| -!- 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:20 |
| 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:21 |
| -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 250 seconds] | 11:22 | |
| @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:23 |
| 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:24 |
| phantomcircuit | but i cant find any simple tools to do this | 11:25 |
| op_mul | I had one at some point | 11:25 |
| 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:26 | |
| -!- Shiftos [~shiftos@gateway/tor-sasl/shiftos] has quit [Ping timeout: 250 seconds] | 11:29 | |
| op_mul | phantomcircuit: duno. the tool does exist though. | 11:29 |
| -!- Glyphnote_ [~Glyphnote@2600:1004:b013:9f11:60d0:515c:8a91:6231] has joined #bitcoin-wizards | 11:30 | |
| -!- Shiftos [~shiftos@gateway/tor-sasl/shiftos] has joined #bitcoin-wizards | 11:31 | |
| -!- epoche [~Glyphnote@2600:1004:b013:9f11:a46c:e148:441f:9ef9] has quit [Ping timeout: 244 seconds] | 11:33 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Ping timeout: 240 seconds] | 11:38 | |
| -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has quit [Quit: iang] | 11:40 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards | 11:43 | |
| -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Remote host closed the connection] | 11:51 | |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has joined #bitcoin-wizards | 12:06 | |
| -!- Dizzle [~Dizzle@2605:6000:1018:c0f5:c520:6d92:eed6:44a9] has joined #bitcoin-wizards | 12:07 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards | 12:10 | |
| -!- soundx [~soundx@gateway/tor-sasl/soundx] has quit [Ping timeout: 250 seconds] | 12:11 | |
| -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards | 12:16 | |
| 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:21 |
| 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:22 | |
| 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:23 |
| -!- 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:24 |
| 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:25 |
| 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:27 |
| gwillen | adam3us: does she actually cough in the presentation? That's hilarious. | 12:33 |
| 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:35 | |
| -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Remote host closed the connection] | 12:52 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection] | 12:55 | |
| -!- hashtagg_ [~hashtag@CPE-69-23-213-3.wi.res.rr.com] has quit [Ping timeout: 240 seconds] | 12:56 | |
| tacotime | adam3us: i'm here and from conformal too | 13:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| -!- 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:10 |
| 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:11 |
| 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:13 |
| -!- op_mul [~op_mul@178.62.78.122] has quit [Quit: Lost terminal] | 13:15 | |
| 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:18 |
| -!- 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:19 |
| 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:20 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| -!- askmike__ [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards | 13:26 | |
| 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:27 | |
| 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:28 |
| -!- 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:29 |
| -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has joined #bitcoin-wizards | 13:30 | |
| -!- askmike__ [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 256 seconds] | 13:31 | |
| 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:32 |
| 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:33 | |
| 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:34 |
| -!- 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:35 | |
| wumpus | justanotheruser: consensus is just not something you can compete on, it's either the same or it's broken | 13:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| wumpus | justanotheruser: no argument there | 13:45 |
| wumpus | kanzure: requiring it to be byte-exact the same may be a requirement too far, but I don't know | 13:46 |
| 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:48 |
| 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:49 |
| -!- Dr-G [~Dr-G@gateway/tor-sasl/dr-g] has joined #bitcoin-wizards | 13:50 | |
| wumpus | kanzure: alternative things? I'm not talking about anything to the press | 13:51 |
| 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:52 |
| justanotheruser | Is there some btcd thing in the news are something? | 13:56 |
| -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards | 14:03 | |
| -!- Profreid [~Profreitt@gateway/vpn/privateinternetaccess/profreid] has quit [Quit: Profreid] | 14:04 | |
| 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:06 |
| -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has quit [Quit: iang] | 14:16 | |
| -!- siervo [uid49244@gateway/web/irccloud.com/x-vemcsspcgbevmbpt] has joined #bitcoin-wizards | 14:23 | |
| -!- op_mul [~op_mul@178.62.78.122] has joined #bitcoin-wizards | 14:31 | |
| -!- 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:32 | |
| justanotheruser | oh, thanks | 14:36 |
| adam3us | justanotheruser: i guess if they inadvertenly forked bitcoin, that'd be negatively newsworthy :| | 14:37 |
| 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:39 |
| Taek | wumpus: I like the idea of setting a firm definition for consensus in something like moxie. | 14:40 |
| 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:41 |
| 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:42 | |
| justanotheruser | even if davec backs down, reddit will probably have some quasi-activism to get btcd funded | 14:43 |
| 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:44 |
| 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:45 |
| 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:46 | |
| -!- siervo [uid49244@gateway/web/irccloud.com/x-vemcsspcgbevmbpt] has quit [] | 14:47 | |
| -!- 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:51 |
| adam3us | justanotheruser: could even cite the patterson presentation. probably she has some journal publication on it also. | 14:52 |
| op_mul | justanotheruser: btcd is almost certainly funded. | 14:55 |
| op_mul | they wouldn't go to all that trouble for no reason | 14:56 |
| 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:57 |
| 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:58 |
| 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 | 14:59 |
| 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:00 |
| 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:01 | |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 | |
| 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:08 |
| adam3us | BlueMatt: (lurkers might find it educational anyway.) | 15:09 |
| -!- lclc is now known as lclc_bnc | 15:10 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.] | 15:14 | |
| -!- iang [~iang@cpc3-lewi16-2-0-cust561.2-4.cable.virginm.net] has quit [Quit: iang] | 15:16 | |
| -!- 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:17 | |
| 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:19 |
| midnightmagic | http://magicrulesunpaa6.onion/Blecher-1983-On_a_logical_problem.pdf for fulltext | 15:22 |
| 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), 5965. | 15:25 |
| 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. 329378, Princeton Univ. Press, Princeton, NJ, 1956. | 15:28 |
| -!- zer0veritas [zer0verita@c-67-185-255-98.hsd1.wa.comcast.net] has left #bitcoin-wizards [] | 15:28 | |
| -!- 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:31 |
| 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:33 |
| -!- 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:35 | |
| -!- 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:36 | |
| -!- eudoxia [~eudoxia@r167-56-16-102.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving] | 15:45 | |
| -!- Shiftos [~shiftos@gateway/tor-sasl/shiftos] has quit [Remote host closed the connection] | 15:51 | |
| -!- Shiftos [~shiftos@gateway/tor-sasl/shiftos] has joined #bitcoin-wizards | 16:00 | |
| -!- MoALTz [~no@user-46-112-49-198.play-internet.pl] has joined #bitcoin-wizards | 16:01 | |
| -!- MoALTz_ [~no@user-46-112-49-198.play-internet.pl] has quit [Ping timeout: 244 seconds] | 16:03 | |
| -!- happycamper [~textual@104-96.105-92.cust.bluewin.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 16:19 | |
| -!- 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:20 | |
| -!- MoALTz [~no@user-46-112-49-198.play-internet.pl] has quit [Ping timeout: 244 seconds] | 16:22 | |
| -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Remote host closed the connection] | 16:30 | |
| -!- MoALTz__ [~no@user-46-112-49-198.play-internet.pl] has joined #bitcoin-wizards | 16:36 | |
| -!- 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:37 | |
| -!- MoALTz_ [~no@user-46-112-49-198.play-internet.pl] has quit [Ping timeout: 245 seconds] | 16:38 | |
| -!- MoALTz_ [~no@user-46-112-49-198.play-internet.pl] has joined #bitcoin-wizards | 16:40 | |
| -!- 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:41 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 16:42 | |
| -!- MoALTz__ [~no@user-46-112-49-198.play-internet.pl] has quit [Ping timeout: 265 seconds] | 16:43 | |
| -!- 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:44 | |
| -!- MoALTz [~no@user-46-112-49-198.play-internet.pl] has joined #bitcoin-wizards | 16:45 | |
| -!- pgokeeffe [~pgokeeffe@101.165.93.194] has joined #bitcoin-wizards | 16:48 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 16:49 | |
| -!- pgokeeffe [~pgokeeffe@101.165.93.194] has quit [Ping timeout: 245 seconds] | 16:53 | |
| -!- 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 | 16:55 | |
| -!- 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:00 | |
| -!- CodeShark [~textual@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-wizards | 17:08 | |
| 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:09 | |
| CodeShark | i.e. extensible headers and abstract data types seem like a good start | 17:10 |
| -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Remote host closed the connection] | 17:17 | |
| -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-wizards | 17:18 | |
| -!- tacotime [~mashkeys@198.52.200.63] has quit [Ping timeout: 255 seconds] | 17:22 | |
| 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:29 |
| -!- 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:30 | |
| 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:36 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| justanotheruser | rusty: 0.7 broke consensus with itself. | 17:50 |
| CodeShark | anyhow, there hasn't really been a deliberate hardfork, has there? | 17:51 |
| justanotheruser | no | 17:51 |
| 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:52 |
| justanotheruser | here is discussion on what 0.7-0.8 was (it's pretty short) http://hastebin.com/ofuqizomuw.xml | 17:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:58 |
| 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 | 17:59 |
| justanotheruser | Increasing the blocksize only solves the problem until the transaction volume matches up with the blocksize once again | 18:00 |
| justanotheruser | and its a controversial hardfork. | 18:01 |
| 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:02 |
| @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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| @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:08 |
| 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:09 |
| @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:10 |
| @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:11 |
| 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:12 |
| @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:13 |
| @gmaxwell | ( https://bitcointalk.org/index.php?topic=149668.0 ) | 18:14 |
| @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:17 |
| -!- Nightwolf [~Nightwolf@unaffiliated/nightwolf] has quit [Read error: Connection reset by peer] | 18:28 | |
| -!- Dr-G2 [~Dr-G@gateway/tor-sasl/dr-g] has joined #bitcoin-wizards | 18:30 | |
| CodeShark | gmaxwell: what about the security model? | 18:30 |
| CodeShark | gmaxwell: I suppose you'd also need to get miners to switch over to the new chain | 18:31 |
| -!- 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:33 |
| BlueMatt | nanotube: wtf, where's gribble? | 18:34 |
| BlueMatt | didnt it used to be here | 18:34 |
| BlueMatt | ? | 18:34 |
| @gmaxwell | no. | 18:35 |
| CodeShark | gmaxwell: how's OP_SIDECHAINPROOFVERIFY coming along? | 18:35 |
| BlueMatt | D= | 18:35 |
| -!- jps [~Jud@23-122-17-11.lightspeed.brhmal.sbcglobal.net] has quit [Quit: jps] | 18:38 | |
| -!- 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:49 | |
| -!- wyager [~wyager@cpe-24-160-153-232.satx.res.rr.com] has joined #bitcoin-wizards | 18:53 | |
| -!- Dizzle [~Dizzle@cpe-72-182-36-12.austin.res.rr.com] has joined #bitcoin-wizards | 18:54 | |
| -!- coiner [~linker@42.116.152.78] has joined #bitcoin-wizards | 19:06 | |
| 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:17 |
| CodeShark | (assuming the consensus model is essentially unchanged) | 19:18 |
| -!- wyager [~wyager@cpe-24-160-153-232.satx.res.rr.com] has quit [Quit: wyager] | 19:27 | |
| -!- 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:28 | |
| -!- 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:29 | |
| -!- 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:30 | |
| -!- 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:31 | |
| 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:33 |
| phantomcircuit | hmm yeah that would be entirely trivial | 19:34 |
| -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has joined #bitcoin-wizards | 19:37 | |
| -!- user7779078 [user777907@gateway/vpn/mullvad/x-cyvyoejhorzmrxib] has quit [Remote host closed the connection] | 19:46 | |
| -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards | 19:47 | |
| -!- wyager [~wyager@cpe-24-160-153-232.satx.res.rr.com] has joined #bitcoin-wizards | 19:49 | |
| -!- wyager [~wyager@cpe-24-160-153-232.satx.res.rr.com] has quit [Client Quit] | 19:50 | |
| -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has quit [Ping timeout: 240 seconds] | 19:52 | |
| tromp | phantomcircuit: the original Momentum proposal (find a hash collision between any two nonces) is progress-full | 19:58 |
| tromp | (the hash output was limited to 50 bits) | 19:59 |
| phantomcircuit | for anybody wondering this is not really for a pow | 19:59 |
| -!- coiner [~linker@42.116.152.78] has quit [Ping timeout: 264 seconds] | 20:04 | |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 265 seconds] | 20:18 | |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards | 20:19 | |
| -!- 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:22 | |
| -!- 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:23 | |
| -!- Starduster_ [~guest@unaffiliated/starduster] has quit [Ping timeout: 240 seconds] | 20:25 | |
| -!- adam3us [~Adium@c31-67.i07-8.onvol.net] has joined #bitcoin-wizards | 20:35 | |
| -!- wserd [5fd38811@gateway/web/cgi-irc/kiwiirc.com/ip.95.211.136.17] has joined #bitcoin-wizards | 20:38 | |
| -!- guest7399 [~guest@5ED11658.cm-7-2a.dynamic.ziggo.nl] has quit [Ping timeout: 240 seconds] | 20:56 | |
| -!- adam3us [~Adium@c31-67.i07-8.onvol.net] has quit [Quit: Leaving.] | 21:15 | |
| -!- coiner [~linker@115.79.55.177] has joined #bitcoin-wizards | 21:17 | |
| -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-wizards | 21:19 | |
| -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has joined #bitcoin-wizards | 21:35 | |
| -!- user7779078 [~user77790@ool-4354b720.dyn.optonline.net] has quit [Ping timeout: 250 seconds] | 21:41 | |
| rusty | Is there a variant of atomic swaps which can tolerate tx malleability? | 21:43 |
| rusty | (Or am I misunderstanding the proposal in Appendix C of the sidechains paper, which seems subject to refund breakage via txmal). | 21:44 |
| -!- 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:45 | |
| @gmaxwell | rusty: malleability will be at the senders option in bitcoin in a couple months-ish. | 21:48 |
| -!- 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:49 |
| -!- 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:50 | |
| @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:52 |
| @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:55 |
| @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:57 |
| rusty | gmaxwell: thanks for the confirmation, at least I'll mention in my 1-page description of atomic swaps. | 21:58 |
| -!- 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:15 | |
| -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: This computer has gone to sleep] | 22:16 | |
| -!- zooko [~user@c-75-70-204-109.hsd1.co.comcast.net] has quit [Ping timeout: 245 seconds] | 22:17 | |
| -!- gavink [uid60113@gateway/web/irccloud.com/x-zesecevohuyezuol] has joined #bitcoin-wizards | 22:50 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 265 seconds] | 22:53 | |
| -!- user7779_ [user777907@gateway/vpn/mullvad/x-aldplgulhmkezhlt] has quit [Remote host closed the connection] | 22:56 | |
| -!- Profreid [~Profreitt@gateway/vpn/privateinternetaccess/profreid] has joined #bitcoin-wizards | 22:59 | |
| -!- NewLiberty [~NewLibert@2602:304:cff8:1580:118d:3cda:742b:32c7] has quit [Ping timeout: 244 seconds] | 23:15 | |
| -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has joined #bitcoin-wizards | 23:16 | |
| -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-wizards | 23:18 | |
| -!- askmike [~askmike@ip241-209-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 244 seconds] | 23:20 | |
| -!- cbeams [~cbeams@unaffiliated/cbeams] has joined #bitcoin-wizards | 23:25 | |
| -!- fanquake [~anonymous@unaffiliated/fanquake] has joined #bitcoin-wizards | 23:35 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.] | 23:44 | |
| -!- NewLiberty [~NewLibert@2602:304:cff8:1580:118d:3cda:742b:32c7] has joined #bitcoin-wizards | 23:57 | |
| --- Log closed Mon Jan 05 00:00:13 2015 | ||
Generated by irclog2html.py 2.15.0.dev0 by Marius Gedminas - find it at mg.pov.lt!