| 00:50:27 | BlueMatt: | andytoshi: last I checked, coinbase employs (or part-time or something) the author of bitcoin-ruby, so tell them |
| 00:50:44 | andytoshi: | BlueMatt: yup, thx, i have gotten in touch with some bitcoin-ruby developers |
| 00:51:16 | petertodd: | andytoshi: coinbase filters their bitcoin-ruby-using implementation via bitcoin core, so exploiting a consensus bug only is a minor DoS attack |
| 00:51:43 | andytoshi: | cool |
| 00:52:11 | andytoshi: | that would explain their "drop off the network" behaviour whenever something weird happens.. |
| 00:52:31 | gmaxwell: | petertodd: they had it exposed directly to the network at one point, I guess you got them to fix that? |
| 00:52:40 | BlueMatt: | gmaxwell: I think that was a while ago |
| 00:52:55 | petertodd: | gmaxwell: they got forked so many times they learned their lesson I guess |
| 03:48:22 | maaku: | maaku is now known as Guest29041 |
| 05:52:32 | justanot1eruser: | justanot1eruser is now known as justanotheruser |
| 05:58:28 | gandalf: | hello |
| 05:58:53 | gandalf: | super3: will storj implement a decentralized hash table to keep track of nodes? |
| 05:59:20 | gandalf: | or how does storj plan to add redundancy, what happens if all nodes go offline? |
| 06:36:44 | super3: | i don't know if i should be happy or sad i got asked about dhts |
| 06:39:02 | Luke-Jr: | lol |
| 06:39:03 | super3: | so, actually yes DHTs are useful because files are hash addressable |
| 06:41:24 | super3: | not directly used in storj, but is inherently useful in the application side to achieve quicker lookups |
| 06:42:28 | super3: | " If a node fails a heartbeat or is unreachable we initiate a network replication process where we take one of the existing copies on network, and transfer it to another." |
| 06:43:17 | super3: | gandalf: that should answer your 2nd question :-P |
| 06:44:06 | gandalf: | ah i see so just a heartbeat method |
| 06:45:48 | super3: | heartbeat is just a seed + file, which gives you a unique hash, more understandable word is just a hash challenge |
| 06:47:20 | super3: | * super3 still feels dirty after the dht question |
| 07:04:18 | gandalf: | lol super3! |
| 07:13:29 | justanot1eruser: | justanot1eruser is now known as justanotheruser |
| 10:37:31 | mquin: | [Global Notice] Coming up this Saturday the 9th in Philadelphia PA, the 5th annual FOSSCON. Check out the speaker schedule at http://fosscon.us/Speakers, and register to attend at http://fosscon.us/Attend. |
| 11:00:23 | wallet421: | wallet421 is now known as wallet42 |
| 11:34:33 | jgarzik: | adam3us, Charles Stross has become notably anti-tech in recent years, for a lot of new tech |
| 11:42:42 | wumpus: | William Gibson also lost most of his interest in (new) tech, his newer books are full of nostalgia, it's almost like science fiction authors age like normal people :) |
| 11:48:28 | wumpus: | though maybe Stross writes science fiction because he's so genuinely scared of tech, and wants to warn people, though he never seemed like an author like that |
| 11:50:34 | jgarzik: | hehe, indeed (RE age) |
| 12:52:48 | fanquake: | fanquake has left #bitcoin-wizards |
| 13:42:24 | wallet421: | wallet421 is now known as wallet42 |
| 14:28:12 | adam3us: | jgarzik: charlie stross from singularitarian to luddite, oh noes. apparently weidai is all focussed on steering the singularity to a human survivable outcome (i presume therefore in a pessimistic sense that he assumes the unsteered one will end badly) |
| 14:40:14 | Pasha: | Pasha is now known as Cory |
| 15:16:25 | Guest29041: | adam3us: yes, weidai would agree (default coarse is end of human race) |
| 15:17:59 | Guest29041: | Guest29041 is now known as maaku |
| 16:33:01 | SomeoneWeird: | SomeoneWeird is now known as Guest30781 |
| 16:42:00 | wallet42: | wallet42 is now known as Guest73884 |
| 16:42:00 | wallet421: | wallet421 is now known as wallet42 |
| 18:48:25 | Starduster_: | Starduster_ is now known as Starduster |
| 19:40:58 | jakoblind: | jakoblind has left #bitcoin-wizards |
| 20:42:18 | Eliel_: | Why not use Ripple's consensus algorithm for syncing mempools of bitcoin nodes? It'd obviously be vulnerable to sybil attacks with the current network model but it doesn't seem to me like it'd make things any worse. |
| 20:42:56 | sipa: | there is no need for that |
| 20:43:09 | sipa: | it is fully validated, no need for trust |
| 20:43:22 | sipa: | you can just sync from everyone |
| 20:44:08 | Eliel_: | well, the only time it'd matter is when there's a double spend attempt. |
| 20:44:22 | Luke-Jr: | Eliel_: that's unavoidable |
| 20:44:37 | Luke-Jr: | Eliel_: you're talking about *policy* consensus now. which is a bad thing |
| 20:45:15 | Eliel_: | Luke-Jr: care to open that up a bit? I'm unfamiliar with what policy consensus means. |
| 20:45:35 | sipa: | well i guess you could have something like trusted peers whose mempools overrides yours in case of conflicts |
| 20:45:40 | Luke-Jr: | Eliel_: nodes aren't all supposed to be using the same rules for mempool or mining |
| 20:46:10 | Luke-Jr: | 0conf double spending is unavoidable |
| 20:46:31 | sipa: | the bad thing is that people could grow to rely on some (even best effort) degree of consensistency |
| 20:46:55 | sipa: | which then breaks with a new software/node/version |
| 20:47:28 | Luke-Jr: | the fact that it only changes with software is kindof a bug right now IMO |
| 20:48:15 | Eliel_: | Luke-Jr: a lack of modularity you mean. Afterall, policy needs to be software too to be usable with bitcoin. |
| 20:48:24 | Eliel_: | but it could be a separate module |
| 20:48:54 | Luke-Jr: | Eliel_: well, we're slowly adding configurable settings |
| 20:49:21 | pigeons: | yeah isstandard is gone now right in head? |
| 20:49:26 | sipa: | no |
| 20:49:33 | sipa: | #bitcoin-dev |
| 20:49:38 | pigeons: | oh oops |
| 20:50:35 | nejucomo: | nejucomo is now known as neju|AFK |
| 21:22:13 | neju|AFK: | neju|AFK is now known as nejucomo |
| 22:15:45 | otoburb: | otoburb is now known as Guest46115 |
| 23:25:25 | Guest30781: | Guest30781 is now known as SomeoneWeird |